Re[2]: C++0x начали урезать
От: Andrei F.  
Дата: 06.12.07 12:06
Оценка: +1 -1 :))) :))) :)))
Здравствуйте, VladD2, Вы писали:

VD>Наивняк ты, однако.

VD>Этому стандарту не зра присвоили номер 0х. Это же шеснадцатиричный префикс, так что в него можно записать любую фиру от 0 до F. А при очень большом желании можно записать и две-три цифры.
VD>Так что 9-ы год — это не очень реальная дата. Вот A-F — это более реальный срок. За одно можно преурочить выход нового стандарта к какому-нибудь юбилею. Например, к столетию Страутрупа.

Я уже года 3 на С++ забил, без крайней нужды стараюсь не иметь с ним дело. Когда приходится какой-нибудь кусок на С++ писать, так просто выворачивает, сколько проблем на ровном месте. Некоторых вещей правда не хватает, но не стоит оно того.
Была слабенькая надежда что комитет еще возьмется за ум, но теперь уже точно не судьба.

PS кстати, что меня удивляет в последнее время — это количество малолетних кулхацкеров, которые с восторгом пишут по форумам что-нибудь типа "оооо, С++ — это так круто, там все так сложно! C# и Java это вааще отстой, там все просто и проги никогда не валятся. А вот в C++ чуть что и сразу GPF, ууу, как круто" Видимо, таким вот будет новое поколение плюсовиков
Re[22]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.12.07 14:24
Оценка: 9 (1) +4 :))) :))
Здравствуйте, VladD2, Вы писали:

VD>С++ можно сделать удобным только если таки отказаться от совместимости. Я бы тупо ввел два режима. 1. Режим совместимости в ктором все по старому. 2. Режим 0х в котором многое запрещено и не допустимо, но зато обеспечивается полноценный контроль. Первое что я бы запретил — это препроцессор. Второе — использование указателей. Третье — программироание шаблонов без концептов.


Прям как в анекдоте:

Застойные годы. Принимают мужика в партию. Председатель комиссии срашивает:
-- Вот скажите, вы курите?
-- Да.
-- А если бы партия вам приказала бросить курить, бросили бы?
-- Да!
-- А вы водку употребляете?
-- Да.
-- А если бы партия вам приказала бросить пить водку, бросили бы?
-- Да!
-- Ну а с женщинами вы встречаетесь? Ну вы, надеюсь, понимаете в каком смысле.
-- Ну да, встречаюсь.
-- А если бы партия вам приказала отказаться от женщин, отказались бы?
-- Э... Да. Раз партия прикажет, значит откажусь.
Тут председатель принимает совсем уж серьезный вид и:
-- А теперь самый важный, как я считаю, вопрос: а если бы партия приказала вам расстаться с жизнью, расстались бы?
-- Да!
-- Вы так быстро отвечаете. Может подумаете еще?
-- Да нахрена мне такая жизнь, без сигарет, водки и женщин?! Забирайте ее всю без остатка!


Зачем кому-нибудь C++ без препроцессора и указателей?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 10:23
Оценка: 7 (2) +1 -2 :)
Здравствуйте, WolfHound, Вы писали:

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


R>>А мне вот это
Автор: remark
Дата: 01.01.07
очень понравилось.

R>>Визуально вроде код на С на несколько вспомогательных строчек длиннее, но по сути один в один с Немерле.
WH>Влад на это еще тогда ответил...


Ну а что он там ответил?
То, что вот это супер пример-убийца, показывающий неописуемую принципиально неповторимую мега-мощь немерле:

| Call("max", [arg1, arg2]) => Math.Max(arg1.Eval(), arg2.Eval())
| Call("min", [arg1, arg2]) => Math.Min(arg1.Eval(), arg2.Eval())
| Call(_, _) => throw InvalidOperationException(this.ToString());


И то, что вот это аналогичный мега-убогий, на 2 порядка худший, принципиально неподдерживаемый код на С++:
 case expr::Call:
     if ("max" == e.name) Math.Max(e.arg1, e.arg2);
     else if ("min" == e.name) Math.Min(e.arg1, e.arg2);
     else throw InvalidOperationException(e);


Ты это имеешь в виду?

Кстати, у меня, например, возникают вопросы к некому ".Eval()" в примере на немерле? Уж не убица ли это типизации? И не замена union'ам? А что, если я опишусь и напишу "name.Eval()", при этом в name по счастливому стечению обстоятельств лежит нечто похожее на число?

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



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[11]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.12.07 14:39
Оценка: 2 (1) +3 -2
Здравствуйте, Nuzhny, Вы писали:

N>А как же скорость? Куча вычислений, многократные проходы по изображению, получение видео от WDM-драйверов, работа с DirectDraw поверхностями... Слава богу, что с новыми процессорами постепенно из кода ассемблерные вставки убираются.


Дык потому я тебе и говорю про ОКамл. Его компиляторы порождают очень приличный код.

N>С С++ всё понятно. На нём (и на С ещё) такие задачи решались и решаются. И библиотек на нём много — те же интеловские OpenCV и IPP.


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

N>Просматривая всякого рода тесты по быстродействию кода на .Net того же C#'па, у меня сложилось не очень благоприятное впечатление.


Ну, это отдельная флэймовая тема. Да и не нетом единым.

N> А ОКамл где потом специалистов на нём искать?


Специалисты есть. Их конечно сильно меньше чем С++-ников. Но зато один тот факт, что человек освоил ОКамл уже говорит о многом. Так что не прийдется заниматься фильтрованием. К тому же можно как-то поощрять собственных программистов осваивать нужные технологии.
Ну, и чтобы о чем-то рассуждать — это что-то надо попробовать.
В конце концов даже если вы никогда не слезете с С++, вы по крайней мере совершенно по другому будете к нему относиться. Да и к программированию в общем тоже.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.12.07 10:49
Оценка: -3 :))
Здравствуйте, Andrei F., Вы писали:

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


Наивняк ты, однако.
Этому стандарту не зра присвоили номер 0х. Это же шеснадцатиричный префикс, так что в него можно записать любую фиру от 0 до F. А при очень большом желании можно записать и две-три цифры.
Так что 9-ы год — это не очень реальная дата. Вот A-F — это более реальный срок. За одно можно преурочить выход нового стандарта к какому-нибудь юбилею. Например, к столетию Страутрупа.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: C++0x начали урезать
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.12.07 06:10
Оценка: :))) :))
Здравствуйте, VladD2, Вы писали:
VD>"Бесполезным" я его не называл. Любой ЯП полный по Тьюрингу можно применять для разработки ПО.
VD>Ну, а кривой и марально устаревший — это не унижение, а констатация факта. Иначе что вообще было говорить о новой версии?
Влад, не трогай маралов Плюсы пожалуй устарели всё же морально, а не по-оленьему.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[29]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.12.07 15:06
Оценка: -5
Здравствуйте, WolfHound, Вы писали:

WH>А так?


Брось ты это. Это упертое создание тебе не переубедить. Ему похрену что молоть, лиш бы свою линию гнуть. Он и сам прекрасно понимает, что молет чушь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: C++0x начали урезать
От: FR  
Дата: 04.02.08 16:24
Оценка: +3 -2
Здравствуйте, VladD2, Вы писали:

VD>Лисп действительно сложен для постижения и реального применения.


Не сложнее любого "обычного" языка. Просто для тех кто уже испорчен бейсиком си или паскалем он "сложен". Тот же Smalltalk также считается "сложным" однако дети его без проблем осваивают.
Re: C++0x *крик души*
От: kov_serg Россия  
Дата: 22.02.08 23:16
Оценка: +1 :))) :)
Здравствуйте, Andrei F., Вы писали:

AF>http://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!330.entry

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

*мдя* как так, какого на%%% он тогда нужен. если в стандарте не будет много поточности. щас все системы идут по пути распараллеливания и переходя на плаформы не x86, а тут её нет да еще и только в 2009.
Сборщик мусора -- вы серьёзно, и без него жили. Но зато, наверняка, добавят новых гвоздей в крышку гроба языка C. Первые два гвозди + + к языку C уже были потом добавились указатели на члены класса, SFINAE, появился stl и boost. Все эти навороты только убивают язык. Такое ощущение что люди не отдают себе отчета и пытаются рекурсивно добавлять всякие рюшечки, навороты и изврещения. То что сделал Александреску ... просто слов нет, это операции на глазах через анальное отверстие, а теперь это делают стандартом. А товарищи из буста нагородили такого... да, это конешно всё замечательно, но это всё построено на заплатках и надстройках и ошибках в работе с шаблонами в разных компиляторах. И еще непонимаю эту манию писать длинные namespace-ы с деситикратной вложенностью как в яве. Зачем?.
Почему нельзя сделать сам язык более выразительным и простым, зачем городить такие огороды и тем более для чего это всё включать в стандарт? Чтоб тотом было тяжелее избавляться от этих раковых опухолей. Народ уже активно пользуется stl, boost-ом, и помоему это не совсем хорошо. Потому что всё это придётся поддерживать в последующих реинкарнациях компиляторах C++. В умелых руках stl, boost замечательный инструмент, который позволяет быстро решать ряд задачь, но:

1. во первых не забывайте для использования таких библиотек надо иметь очень хорошие познания в довольно неочевидных закоулках языка C++ а этим похвастаться никто не может, постоянно выясняется что есть ещё что то чего не знал.
(Я тут в форуме наблюдал сообщения типа помогите написать шаблон. Почему? Потому шаблоны в том виде что есть не являются тем средством которое позволяет писать код естественным образом. Это всего лиш жалкое подобие метаязыка. И написание шаблонов для некоторых задач превращается в искуство или вообще в задачу которая не имеет решения и приходится делать обходные пути. Шаблоны в том виде что есь -- зло. Для для узкого класса задач они незаменимы, но то что с ними делают в бусте... Я вообще не понимаю как люди досих пор пишут компиляторы C++ которые это компилируют.)
2. всё вот это придётся передавать следующим поколениям программистов, а они уже сейчас смотрят на это с недоверием. Вот вы к примеру знаете все тонкости этого ... языка и понимаете в деталях как это работает и поэтому аккуратно обходите грабли на которые остальные регулярно наступают. А способны ли вы расказать все тонкости и подводные камни другому человеку или (группе студентов) что бы они всё поняли так же и как вы в совершенстве овладели этими знаниями. Скорее всего нет.
3. все готорвые решения имеющиеся в boost и stl ведут как ни странно к деградации программистов. находятся люди которые не удалить в строке скобочки средствами stl. не смотря на то что на языку C эта проблемма решается двумя строчками кода. Люди даже не знают как устроены сбалансированные деревься. Бегают итератором по мапам и удаляют элементы и недоумевают почему глючит. Даже поиск максимума превращается в тяжелейшую неразрешимую проблемму без всех этих мягких и удобных средств stl в которых они не ориентируются. Все эти плюшевые подушечки и готовые решения превращают язык C++ в быдлокодерский язык. И ведут к привыканию к комфортным креслам. А расслабляться не стоит. Враг не дремлет.
4. С введением столь сложного стандарта, никому в голову не придёт писать свой компилятор C++0x и выживут только компиляторы основанные на старых C++ наследуя все косяки и грабли заложенные в них. Вообще-то это тоже очень печально. Т.к. есть огромное число процессоров и микроконтроллеров для которых язык типа C++ был бы не заменим, особенно в условиях много поточности. Но там толь asm и в лучшем случае C. т.к. это очень простые для написания компиляторы.
Более того всё совершенствования языка свёдётся и исправления всё новых и новых косяков которые будут появляться в геометрической прогрессии. Так что это тоже приведёт к торможению развития.
5. и еще все библиотеки как-то нацелены на совершенно общие задачи, и никак не нацелены на упрощение решения типовых задач и на повышения читабельности и выразительности кода. Почему в boost.threads не команды sleep(double seconds)? неужели столь ненужная функция. А эта любось к лямда вычислениям -- я досих пор не понимаю какого -- в каких практических задачах без этого нельзя обойтись?

Я вот лично не понимаю почему язык нельзя сделать много уровневым как слоёный пирог.
0 уровень разметка (аля html) что бы можно было вставлять в текст картинки и прикреплять файлы, делать интерактивной коментарии и примеры.
1 уровень. мета язык — язык который расширяет функциональность парсера, компилятора, кодогенератора и линковщика. (код который нужен до компиляции, вовремя и после)
2 уровень собственно алгоритмический язык программирования (будующий исполняемый код)
3 декларативный уровень в языке был бы очень к стати
3' уровень описания не алгоритмов, а процессов (как в vhdl)
можно и четвёртый уровень добавить управления кодом (проверка, проверка соблюдения правил, рекомендации и инвариантов).
+набор библиоткек для решения повседневных задач (обработка отказов и событий, строки, кодировки теста, математика, время, память, ввод/вывод, файловая система, многопоточность, сеть и взаимодействие cs p2p, гуи, контейнеры, контейнеры для данных на внешних носителях, и ряд других)

Поясню
2 описывает пошагово что надо сделать для решения задачи
3 описывает что есть и что надо получить, а 1-ый сам ищет алгоритм для решения задачи
3' описывает взаимосвязи и события в системе (и может быть использован для проверки правильности работы программы или для синтеза схем как в программируемой логике)

Что то я разошелся. Итого если так пойдёт то смерь языка C++ не загорами, язык C++0x может родиться вообще мёртвым языком.

Мне нужен простой в изучении, выразительный, понятный, легко раширяемы и мощный язык, генерящий эффективный код, который легко портировать на разные платформы с поддержкой распараллеливания (не просто много поточности но и связанных с этим типичных задач). Неужели я одинок в подобного рода желаниях? Неужели всех устраивает то что есть?
Може есть такие языки? а я не вкурсе
Re[35]: C++0x начали урезать
От: Трурль  
Дата: 05.02.08 10:10
Оценка: 1 (1) +1 :))
Здравствуйте, eao197, Вы писали:

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


C++’s success in real-world use also led to influences that are less beneficial. The frequent use of the ugly and irregular C/C++ style of syntax in modern languages is not something I’m proud of.

Re[54]: C++0x начали урезать
От: VoidEx  
Дата: 07.02.08 05:39
Оценка: 1 (1) +3
Здравствуйте, WolfHound, Вы писали:

EC>>Вот если бы LINQ приделали на макросах это был бы убийственный аргумент.

WH>Если бы оно было сильно надо...

Ну уж? Не надо лукавить. Я даже переписку читал, где авторам языка предлагали добавить новый тип макросов специально для того, чтоб можно было реализовать тот же LINQ.
IT не раз говорил, что в таком случае стоит признать, что макросы не могут создавать нормальные DSL, и что все обходные пути реализации LINQ (как то <# select... #> и прочее) — это фигня, а не решение.

А потом решили, что оно не сильно надо. Понятно.
Re[37]: C++0x начали урезать
От: Andrei F.  
Дата: 01.02.08 13:42
Оценка: +1 -1 :))
Здравствуйте, eao197, Вы писали:

E><...обычное безсодержательное словоблудие поскипано, хотя над отсутствием интеропа у D поулыбался...>


Это хорошо, что ты его поскипал. Тебе не пришлось его писать, мне не пришлось его читать. Молодец
Так что, в D уже появился интероп с С++? И как это выглядит?

E>Я таки услышу ответ на вопрос о том, к пределу какой сложности приближается разработка современных языков программирования?


Я надеюсь, мне не придется читать лекцию о разнице между монолитными и модульными системами?

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


Меньше проблем в разработке языка — больше времени на обдумывание и проектирование. Лучше продуман язык — удобнее его использовать. И так далее.
А то за некоторые "решения" в C# так и хочется разработчикам руки пообрывать.

E>Ну хотя бы тем, что Nice -- не функциональный язык программирования.


Ну, тем хуже для него
Re[54]: C++0x начали урезать
От: FR  
Дата: 06.02.08 09:29
Оценка: :))) :)
Здравствуйте, Andrei F., Вы писали:

AF>С трудом представляю, что можно менять в ядре, тем более — постоянно


Я думаю просто нужно чтобы Aлександреску заинтересовался Немерле
Re[55]: C++0x начали урезать
От: WolfHound  
Дата: 06.02.08 10:02
Оценка: +1 -1 :))
Здравствуйте, FR, Вы писали:

AF>>С трудом представляю, что можно менять в ядре, тем более — постоянно

FR>Я думаю просто нужно чтобы Aлександреску заинтересовался Немерле
Он ничего не придумает.
Да и что можно придумать если уже есть полные по Тьюрингу макросы?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[62]: C++0x начали урезать
От: FR  
Дата: 06.02.08 14:46
Оценка: +3 -1
Здравствуйте, WolfHound, Вы писали:

FR>>Ничего ни нужно. Бесполезно, просто нужно чтобы прошло какое-то время и новая игрушка тебе наскучила, тогда можно будет нормально разговаривать. Хотя желания общатся с тобой у меня с каждым разом становится намного меньше. Сейчас разговор точно не получится, пока.

WH>Как всегда... одни эмоции и никаких аргументов.

У тебя конечно сообщения абсолютно лишены эмоций

Аргументы я тебе привел в виде трех примеров которые на макросах Немерли полноценно не реализуются, ты же мне в ответ приводишь пример в котором совершено не используются макросы и который показывает использование механизма который является частным очень ограниченым случаем того что я просил. На второй вопрос отвечаешь что это не нужно. На третий опять приводишь частный случай. Нормально.
Re[58]: C++0x начали урезать
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 06.02.08 16:31
Оценка: +4
Здравствуйте, WolfHound, Вы писали:

FR>>Даже я могу кучу вещей придумать в которых полные по тьюрингу макросы мало чем помогут, например добавь подержку продолжений ( http://en.wikipedia.org/wiki/Continuation ),

WH>
WH>    public static MapFilteredLazy[T, U](this lst : list[T], fn : T -> option[U]) : SCG.IEnumerable[U]
WH>    {
WH>        def loop(_)
WH>        {
WH>        | head :: tail =>
WH>            match (fn(head))
WH>            {
WH>            | Some(result) => yield result;
WH>            | None => ();
WH>            }
WH>            loop(tail);
WH>        | [] => ();
WH>        }
WH>        loop(lst);
WH>    }
WH>


Это continiations?

continuations — это call/cc. Нарисуй его, пожалуйста. Как решить частные случаи, которые решает call/cc, не особо интересно. Вопрос был о поддержке продолжений.

FR>>или мультиметов в стиле CLOS,

WH>Мультиметоды зло ибо их семантика слишком размыта.
WH>Слишком много если...

Мультиметоды — зло, хотя бы по той причине, что их нет в Немерле

FR>>или нормальную ленивость,

WH>Что значит нормальную?
WH>Эта нормальная или нет http://nemerle.org/Lazy_evaluation

Семантически — думаю да. Вроде delay/force там есть.

Остальное — детали реализации. Например, наверняка strictness-analysis нет, объекты всегда будут создаваться, даже если используются только их части (например, constructor specialisation нет) и т.д.

Поэтому практически насколько это нормальная ленивость — не знаю.

На самом деле тут о чём разговор? О том, что если макросы есть, то всё — можно уже не расширять язык или что?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[40]: C++0x начали урезать
От: Трурль  
Дата: 08.02.08 06:17
Оценка: :))) :)
Здравствуйте, VladD2, Вы писали:

FR>>Угу только по моему в резулmтате получаются больше "пользователи сахара"


VD>Если переведешь это предожение на Русский, то можно будет осбудить его.


Ну эта, шуга-юзеры получаюцца.
Re[46]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.02.08 11:43
Оценка: -2 :))
Здравствуйте, WolfHound, Вы писали:

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


E>>Ни в D, ни в Nice, ни в Nemerle, я не видел возможности использования old в постусловях. Т.е. ни один из этих языков не реализует оригинальной концепции Design By Contract. И компиляторы этих языков созданы на разных принципах. Так какое же преимущество имеет микроядро с макросами Nemerle, если контракты там такие же ущербные, как и в других языках?

WH>Возьми да добавь.
WH>Там все просто.
...
WH>Все что нужно это запомнить аргументы функции до вызова body и передать их в check.
WH>Думаю с этим даже ты справишься.

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

E>>Более того, использование синтаксиса и блоков кода Ruby для декларативных описаний -- это общепринятая практика в Ruby, так что нельзя говорить, что язык на это расчитан не был. И в Ruby вся эта магия делается не макросами, не изменением синтаксиса, а обычными библиотеками.

WH>А макросы чем тебе не библиотеки?

Я уже пытался объяснять про проблемы совместного использования нескольких разных синтаксических макросов с одинаковыми ключевыми словами. Но вам выгоднее не обращать на них внимания. Хотя как раз в этом отличие между макросами и библиотеками и состоит -- в отсутствии конфликтов.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: C++0x начали урезать
От: palm mute  
Дата: 14.12.07 09:45
Оценка: 20 (3)
Здравствуйте, FR, Вы писали:

FR>Я заглядывал и показалось что что-то не так

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

Запускаешь make -f Makefile.alone, и брюки превращаются в элегантные шорты.
Я вот помаялся дурью, чтобы таки определить длину и диаметр.

В исходниках lua-ml мы учитываем только *.ml, т.к. сигнатуры модулей в *.mli полностью дублируются в *.ml и генерируются из одного источника. Далее, мы удаляем автоматически сгенерированные лексер и парсер, вместо них мы будем учитывать только соответствующие *.mll и *.mly:
$ for i in luaparser.mli luaparser.ml luaparsex.mli luaparsex.ml luascanner.ml ; do mv $i $i.auto ; done


Считаем строки:
$  wc -l *.ml luascanner.mll luaparsex.mly
    25 bench.ml
    12 log.ml
    86 luaast.ml
   112 luabaselib.ml
    68 luacamllib.ml
   107 luaclient.ml
   142 luafloat.ml
   270 luahash.ml
   163 luaiolib.ml
   477 lualib.ml
    31 luamathlib.ml
    25 lua.ml
    49 luarun.ml
   266 luastrlib.ml
   525 luavalue.ml
    34 main.ml
   142 srcmap.ml
   361 luascanner.mll
   212 luaparsex.mly
  3107 total


Теперь оцениваем версию на C. Сгенерированный парсер тоже удаляем, заголовочные файлы тоже не рассматриваем (просто, чтобы никто не возмущался , по-хорошему надо бы их оставить, т.к. все определения типов находятся там, дублирования, как в случае Окамла, нет):
$ wc -l `find . -name *.c -or -name '*.stx'` # *.stx - это исходники парсера
   300 ./src/inout.c
   319 ./src/hash.c
   191 ./src/fallback.c
   796 ./src/lua.stx
   156 ./src/func.c
    58 ./src/mem.c
   341 ./src/lex.c
   333 ./src/undump.c
  1330 ./src/opcode.c
   145 ./src/tree.c
   278 ./src/table.c
   190 ./src/luac/print.c
   105 ./src/luac/luac.c
   248 ./src/luac/dump.c
    71 ./clients/lua/lua.c
   276 ./clients/lib/old/strlib.c
   230 ./clients/lib/old/mathlib.c
   618 ./clients/lib/old/iolib.c
   573 ./clients/lib/strlib.c
   230 ./clients/lib/mathlib.c
   295 ./clients/lib/iolib.c
  7083 total


Получаем разницу в 2 раза, что и требовалось доказать.
Re[60]: C++0x начали урезать
От: VoidEx  
Дата: 08.02.08 19:45
Оценка: 9 (1) +2
Здравствуйте, VladD2, Вы писали:

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


VE>>Не смеши, текущими макросами LINQ не сделаешь, хоть убейся, я в курсе почему. Либо другой синтаксис, либо <# #> (что тоже другой синтаксис) или еще какие костыли. Надо систему макросов менять.


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


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

Я точно так же, как и lomeo прибыл к середине спора и сложилось впечатление, что "на макросах можно все". Стоило уточнить, что не все так гладко в датском королевстве, и что даже LINQ в полном соответствии синтаксиса на текущий момент не реализуется, так такие ответы пошли, как будто я святыню попрал какую. Ну уж извините, ни коим разом не хотел.
Вряд ли это Вас успокоит, но языки с микроядром и метапрограммированием мне тоже нравятся больше, хотя я не могу с уверенностью сказать, что за ними будущее, ибо не Нострадамус, в отличие от пророков Nemerle.

За сим откланяюсь и прошу в таком тоне мне не отвечать.
Советую также перед отправкой сообщения его перечитывать. И ошибки исправляются, и пыл свой можно поубавить по ходу ревизии.
Re[34]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.02.08 08:13
Оценка: 2 (2) +1
Здравствуйте, Andrei F., Вы писали:

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


E>>И какие данные? Учитывается ли опыт Lisp-ов?


AF>Лисп — вполне удачный язык, из него очень многие заимствовали, да и применяется он не так уж редко. Его главная проблема — неудобный синтаксис. Но в Немерле такой проблемы нет.


Тогда нужно определиться в критерии "иметь будущее". Если под этим понимается "стать мейнстримом", то это одно, а если "применяться кое-где" -- то совсем другое.

Lisp мейнстримом не стал. Хотя тогда его синтаксис вряд ли был камнем преткновения -- выбирать-то было особо не из чего. И даже знаменитого C-шного синтаксиса, который сейчас является чуть ли не ключем к успеху языка, тогда еще не было. Так что причина неудачи мейнстримовых притязаний Lisp-а в неудобном синтаксисе не выглядит очень убедительной. Скорее это отговорка для тех, кто не может перестроиться на другую волну.

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

Если же под будущим понимать просто существование в каких-либо нишах (как это сейчас с Lisp-ами и Schema-ми происходит), то почему тогда у D и иже с ним нет будущего? Местами я бы сам с удовольствием использовал бы D вместо C++. И мне кажется, вы не представляете себе, какой прогресс в действительности происходит вокруг D, насколько он обрастает всякой всяченой.

И еще один экскурс в историю -- в начале 2000-ных у Ruby так же не было будущего. Это был просто еще один скриптовый язык, мало кому известный и мало кем используемый. Таковым он и оставался года до 2005-го. Зато как все изменилось за последние несколько лет!

E>>Тем не менее хотелось бы услышать более конкретные причины, по которым у Scala нет будущего.


AF>Помрет под собственной тяжестью. Языки монолитного типа уже вплотную подошли к пределу сложности.


Пределу сложности чего?
Современные языки сложно разрабатывать? На примере чего это видно? Разве были жалобы от Хальсенберга о том, что они C# 3.0 делали на пределе возможностей? Или может быть Одерски заявил, что они больше не в состоянии развивать Scala? Что-то не припомню такого, наоборот, релизы языка выходят с завидной стабильностью и переодичностью.

Или может речь идет о пределе сложности восприятия языка пользователем? Мол столько фич насовали в язык, что мало кто способен с ними разобраться. Так а чем Nemerle здесь лучше?

E>>В Nice автор реализовал все, что хотел.


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


Все когда-то происходит в первый раз.

AF>Всегда есть что-то еще, что хочется добавить и улучшить. Скорее всего, причины другие — "сделал всё, что смог" или "просто надоело"


Или "сделал все, что хотел, теперь нужно посмотреть, нужно ли это вообще кому-то".

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


Да посмотрите. А то по вашим словам Nice очень похож на Scala. Хотя из похожести там только похожий набор ключевых слов: let, var, class, for, ...


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[24]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.12.07 14:37
Оценка: 1 (1) +2
Здравствуйте, Курилка, Вы писали:

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


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


VD>>>Тот же Немерле проектировался с нуля и без компромисов для (скажем) совместимости с С.

J>>Это он сейчас так проектировался.
J>>А вот когда ему стукнет 20 лет, как С++, тогда ему придется обеспечивать прежде всего совместимость с самим собой, если, конечно, он собирается эволюционировать.

К>Только не стоит забывать, что и 20 лет назад он проектировался исходя из обратной совместимости с C


Вот через 20 лет кто-нибудь поставит Nemerle в упрек то, что он создавался под .NET.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[60]: C++0x начали урезать
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 07.02.08 20:45
Оценка: 1 (1) +2
Здравствуйте, VladD2, Вы писали:

VD>Я правильно понял, что по реализуемости мультиметодов и т.п. вопрос отпал?


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

С одной стороны — неточность формулировки, с другой — придирка к словам. Обе стороны отличились, а спор выеденного яйца не стоит, т.к. целей у него два

1. Либо доказать WolfHound-у (и компании), что на макросах сделать всё нельзя, но я думаю, он это и так понимает.
2. Либо доказать FR (и компании), что мультиметоды Немерле не нужны. Но его это тоже мало интересует.

Остальное — детали. Коротко — о разном говорят, IMHO.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.12.07 10:49
Оценка: -3
Здравствуйте, Cyberax, Вы писали:

C>Только консервативный (т.е. мегахак).


А как ты вообще видишь себе прикручивание точного ЖЦ к языку допускающему небезопасные операции с памятью и в котором отсуствуют такие примитивы как массивы?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: C++0x начали урезать
От: Sni4ok  
Дата: 07.12.07 18:42
Оценка: +1 -2
Здравствуйте, Andrei F., Вы писали:

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


то что не будет GC- слава богу, иначеб сделали из языка- помойку.
А насчёт многопоточности- пофиг, буст он и в линуксе буст.
Re[16]: C++0x начали урезать
От: WolfHound  
Дата: 14.12.07 12:38
Оценка: +2 -1
Здравствуйте, remark, Вы писали:

R>И то, что вот это аналогичный мега-убогий, на 2 порядка худший, принципиально неподдерживаемый код на С++:

R>
R> case expr::Call:
R>     if ("max" == e.name) Math.Max(e.arg1, e.arg2);
R>     else if ("min" == e.name) Math.Min(e.arg1, e.arg2);
R>     else throw InvalidOperationException(e);
R>

Нет никаких arg1 и arg2. Вторым параметром идет список. Также нужно вычслить выражения перед тем как их скормить Min/Max
Те как минимум должно быть так:
    case expr::Call:
        if ("max" == e.name && e.args.size() == 2) Math.Max(eval(e.args[0]), eval(e.args[1]));
        else if ("min" == e.name && e.args.size() == 2) Math.Min(eval(e.args[0]), eval(e.args[1]));
        else throw InvalidOperationException(e);

И это весьма примитивный пример.
При попытке повторить это у тебя будет ужасное нагромаждение кода
| Call (OpCode ("=="), [nested_cond,
    Parm where (expr = TExpr.TypeConversion(TExpr.Literal(Literal.Bool(true)), _, _))], _) =>
    emit_branch(nested_cond.expr, else_label)


R>Кстати, у меня, например, возникают вопросы к некому ".Eval()" в примере на немерле? Уж не убица ли это типизации?

С какой это стати?

R>И не замена union'ам?

Нет. union'ы не типобезопасны.

R>А что, если я опишусь и напишу "name.Eval()", при этом в name по счастливому стечению обстоятельств лежит нечто похожее на число?

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

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

Они объективны нравится это тебе или нет.
Ибо код на на С сложен для поддержки и восприятия. Код на С практически не контролирует компилятор.
Что скажет компилятор если ты ошибешься с индексами или забудешь else throw ?
Да ничего он не скажет.
И на тестовых примерах вероятно все отработает.
А у клиента все свалится.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 18.12.07 07:02
Оценка: -3
Здравствуйте, Стэн, Вы писали:

С>А теперь от задач абстрактных, к задачам конкретным. Сейчас я занимаюсь разработкой библиотеки асинхронного программирования act-o
Автор: Стэн
Дата: 27.11.07
. На данный момент она написана на C++ и используется только из C++. Не касаясь вопроса о том, что писать клиентские приложения на C++ — некошерно, обратимся к вопросу на чем писать runtime? Для новых эксперементальных runtime'ов я решил отказаться от С++ и писать на чистом C, так как он проще и дров наломать в нем сложнее... В связи с моральным устареванием С, как несколько раз я читал в этой теме, у меня вопрос — есть ли ему какая-то замена? Но только, чтобы программы компилировались в native-код, чтобы был полный и простой доступ к низкоуровневым API ОС и железу, чтобы программы получались быстрыми, и чтобы была возможность относительно легко портировать программы на разные ОС.



На немерле зато строк кода будет меньше. А на OCaml всё будет математически выверенно. Ну и что, что работать не будет



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[23]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.01.08 05:26
Оценка: +1 -2
Здравствуйте, CreatorCray, Вы писали:

VD>>Я бы тупо ввел два режима.

VD>>2. Режим 0х в котором многое запрещено и не допустимо, но зато обеспечивается полноценный контроль. Первое что я бы запретил — это препроцессор. Второе — использование указателей. Третье — программироание шаблонов без концептов.
CC>С такими ограничениями этот второй режим тогда нафиг никому не нужен. Это уже не C++.

Это зависит от равития личности. Если она ничего кроме С++ в своей жизни не видела, то несомненно — да.
Хорошие же С++-программисты и в данный момент используют ограниченный сабсет С++ прибегая к его опасным частям только по необходимости. Проблем у такого подхода две 1) контроль возлагается на человека и стало быть надежность программ гарантировать нельзя, 2) языковые средства подобного сабсета сильно ограничены.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: C++0x начали урезать
От: Константин Л. Франция  
Дата: 10.01.08 17:20
Оценка: +1 -2
Здравствуйте, VladD2, Вы писали:

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


КЛ>>Если мне надо кого-то заколбасить на званом ужине, я рассмотрю вилку как неплохое орудие убийства, особенно если я умею ей профессионально ообращаться.


VD>Не. Я любитель. Есть люблю ей, а так — нет.


КЛ>>С серьезной мат. подготовкой, понимаешь! Влад, хватит хрень всякую нести. Что там проектировать? Апполон 13? Какая еще мат. подготовка?


VD>

The PPG group at MSR Cambridge have been designing and prototyping support for "generics" in C# and the .NET Common Language Runtime. Generics are also known as polymorphism, parameterized types, or templates.

VD>http://research.microsoft.com/projects/clrgen/

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

VD>Особо обрати внимание на год.

VD>Кстати, один из мужиков занимавшийся дженериками разработал F#.

F# теперь супер мега язык? "Разработал"... Звучит то как.

КЛ>>Если отбросить пыл, то никакая мат подготовка и коммерческость программистов еще ничего не гарантирует.


VD>Это уже не совсем так. В МС взяли на работу многих исследователей. В том числе тех что создали Хаскель, F# и т.п.


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

КЛ>>Тут все правда. Но шаблоны это концептуально законченная идея. Нравится она тебе или minorlogic'у или не нравится — на ее законченность это не влияет.


VD>Шаблоны созданы "из лучших побуждений" человеком который не имел достаточно полготовки. Их правда, что делали для того чтобы "сделать vector<T>". Ошибок было сделано уйма.


Достаточно подготовки? Не смеши. Есть только 2 концепции, которые отличают templates от generics: констрейнты, сохранение "исходного" кода для последующей кодогенерации. И все. Ничего революционного. Сомневаюсь, что Страуструп не рассматривал эти фичи при проектировании. Просто он их сознательно выкинул.

ПС: косяки в темплейтах есть. Но они скорее сишные, чем темплейтные. То есть атавизмы. Концепты поправят констрейнты. Со вторым ничего делать просто не надо.
Re[51]: C++0x начали урезать
От: WolfHound  
Дата: 05.02.08 16:19
Оценка: +3
Здравствуйте, eao197, Вы писали:

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

В ситуации когда язык никому не нужен роме некоторых контор куда его проталкнули за откаты?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[58]: C++0x начали урезать
От: FR  
Дата: 06.02.08 13:51
Оценка: +1 -1 :)
Здравствуйте, WolfHound, Вы писали:

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


FR>>Даже я могу кучу вещей придумать в которых полные по тьюрингу макросы мало чем помогут, например добавь подержку продолжений ( http://en.wikipedia.org/wiki/Continuation ),

WH>
WH>    public static MapFilteredLazy[T, U](this lst : list[T], fn : T -> option[U]) : SCG.IEnumerable[U]
WH>    {
WH>        def loop(_)
WH>        {
WH>        | head :: tail =>
WH>            match (fn(head))
WH>            {
WH>            | Some(result) => yield result;
WH>            | None => ();
WH>            }
WH>            loop(tail);
WH>        | [] => ();
WH>        }
WH>        loop(lst);
WH>    }
WH>


Угу тогда функторы аля STL это замыкания
Сходи все таки по ссылке, посмотри как в схеме сделано.

FR>>или мультиметов в стиле CLOS,

WH>Мультиметоды зло ибо их семантика слишком размыта.
WH>Слишком много если...

То есть все что не можем сделать на макросах зло, понятно.

FR>>или нормальную ленивость,

WH>Что значит нормальную?
WH>Эта нормальная или нет http://nemerle.org/Lazy_evaluation

Сравнивай с хаскелем или клейном.

FR>>думаю в этот список можно еще немало вещей добавить и со временем список будет только расти.

WH>Попробуй.

А зачем, ты скажешь или не нужно или приведешь частично коряво сделаную реализацию и скажешь что этого достаточно. Это все равно что обчитавшемуся Александреску говорить что boost::lambda корявое убожество.
Re[75]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:37
Оценка: :)))
Здравствуйте, FR, Вы писали:

FR>Жаль у меня по работе завал, так что флеймить некогда.


Не фига себе некогда!!!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[51]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 15:39
Оценка: +3
Здравствуйте, eao197, Вы писали:


E>Тогда два вопроса:

E>* если все это можно сделать без макросов, на анотациях, то зачем макросы?
E>* что делать с макросами, которые в анотации не засунуть? Насколько я понимаю, вещи типа using и for в Nemerle -- это макросы. Они так же функциями заменяются?

Мне кажется, что самое время хочть чуть-чуть почитатиь о премете обсуждения. Если ты дилетант в данной области, то не лезь с суждениями и верь тому что тебе говорят, а если хочушь судить, то разберись в вопросе. А то на подобные вопросы тебе уже раз 10 отвечали, но ты задаеш их снова и снова.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[67]: C++0x начали урезать
От: Andrei F.  
Дата: 11.02.08 04:39
Оценка: -3
Здравствуйте, eao197, Вы писали:

AF>>Вероятно, придется делать неуправляемый класс-наследник и обертки для управляемых функций.


E>И после этого вы еще предъявляете какие-то претензии к D?


Честное слово — удивляюсь, как человек с такими проблемами с логикой вообще может работать программистом.
Это один-единственный сценарий интеропа, в котором C++/CLI предлагает примерно такое же плохое решение, как и D. Что может доказать одно исключение? Ничего.
Если ты хочешь реально что-то доказать — приведи список наиболее типичных задач, которые решаются интеропом, и сравни решение для них на D и C++/CLI.
Re[13]: C++0x начали урезать
От: palm mute  
Дата: 13.12.07 19:14
Оценка: 45 (2)
Здравствуйте, FR, Вы писали:


FR>Вот тут http://www.cminusminus.org/rsync/dist/lua-ml-20071123.tar.gz лежит интерпретатор Lua 2.5 написанный на Ocaml, тут он же http://www.lua.org/ftp/lua-2.5.tar.gz на си, и почему то сишная версия поменьше в размерах


FR>С (*.с *.h) 194 kb

FR>Ocaml (*.nw) 222 kb

FR>(я еще не копался что там внутри так что если кто раскопает и разъяснит почему буду рад)


Тебя не насторожило странное расширение *.nw для исходников на Окамле? Окамловская реализация использует NoWeb, систему literate programming. Загляни внутрь и прикинь на глазок количество комментариев.
Типичный исходный файл этого интерпретатора выглядит так:
...Once we have [[Map]], we can provide a mapping between a Lua name like
[[Pair.mk]] and its {\ocaml} implementation. The [[register_module]]
function takes a list of (name, value) pairs, where a value can be a
function. The conversion between the interpreter's internal
representation and our's is provided by a clever infix function [[**->]]
that makes the conversion function look like a function type. The
[[Map]] module is here essential to name the user-defined argument
types. 

<<register [[Pair]]>>=    
C.register_module "Pair"
    [ "mk", V.efunc (V.value **-> V.value **->> Map.pair) Pair.mk
    ; "fst",V.efunc (Map.pair **->> V.value)              Pair.fst
    ; "snd",V.efunc (Map.pair **->> V.value)              Pair.snd
    ] g;
@

The registration of the [[Char]] module shows how to deal with errors in
conversions. [[Char.mk]] expects a string whose first character is used...
Re[41]: C++0x начали урезать
От: WolfHound  
Дата: 04.02.08 15:23
Оценка: 39 (2)
Здравствуйте, eao197, Вы писали:

AF>>А что он реализован только под Windows — не очень хорошо, но мне это проблем не создает.

E>Ну то есть, вне .NET/Windows жизни ты не видишь. Так и запишем.
Демагог млин.
Из того что сказал Andrei F. это не слудет.

E>Зато вот те, кто затеял возню с микроядром и метапрограммированием, потеряли мотивацию к дальнейшей разработке.

Они сделали компилятор продакшен качества в отличии от остальных. Даже в C# с их ресурсами багов как минимум не меньше.
И это при том что в nemerle один из самых мощных алгоритмов вывода типов.
        public Init(configPath : string) : void
        {
            def config = FastcgiDaemonsWatcherConfig.ParseFile(configPath);
            logPath_ = config.LogPath;
            def gates = Hashtable();
            mutable port = config.StartPort;
            foreach (gate in config.Gates)
            {
                mutable argCount = 0;
                mutable args = "";
                def startPlink()
                {
                    when (argCount > 0)
                    {
                        def plink = System.Diagnostics.Process();
                        plink.StartInfo.FileName = config.PlinkPath;
                        plink.StartInfo.Arguments = $"-ssh $args -pw $(gate.Password) $(gate.Login)@$(gate.Host)";
                        plink.StartInfo.UseShellExecute = false;
                        plink.StartInfo.CreateNoWindow = false;
                        plink.StartInfo.RedirectStandardError = true;
                        plink.StartInfo.RedirectStandardInput = true;
                        plink.StartInfo.RedirectStandardOutput = true;
                        when (!plink.Start())
                            throw Exception("Can't start plink.");
                        plinks_ ::= plink;
                        args = "";
                        argCount = 0;
                    }
                }
                def addPlinkArg(daemonHost, daemonPort)//*1*
                {
                    def localPort = port;
                    def localHost = "localhost";
                    args += $" -L $localPort:$daemonHost:$daemonPort ";
                    ++port;
                    ++argCount;
                    when (argCount >= 20)
                        startPlink();
                    (localHost, localPort);
                }
                gates.Add(gate.Name, (addPlinkArg, startPlink));
            }
            daemonsStatusGetters_ = config.Daemons.Map(daemon =>
            {
                def makeTCPGetter(name, host, port)
                {
                    () => (name, FastcgiDaemon.GetFastcgiDaemonStatusTCP(host, port))
                }
                match (daemon.GateName)
                {
                | null | "" =>
                    makeTCPGetter(daemon.Name, daemon.Host, daemon.Port);
                | gateName =>
                    def (Some((addPlinkArg, _))) = gates.Get(gateName);
                    def (host, port) = addPlinkArg(daemon.Host, daemon.Port);//*2*
                    makeTCPGetter(daemon.Name, host, port);
                }
            });
            gates.Values.Iter((_, startPlink) => startPlink());
        }

Типы в строке *1* были выведены из строки *2*.
Нука покажи мне язык с системой типов не Hindley–Milner который на такое способен.
Да и вобще обрати внимание на то с каким цинизмом написана данная функция.

Кстати это кусок мониторинга продакшен кластера.

using System;
using System.Console;
using SCG = System.Collections.Generic;
using Nemerle;
using Nemerle.Utility;
using Nemerle.Collections;

/*
Consider the number 45656. 
It can be seen that each pair of consecutive digits of 45656 has a difference of one.
A number for which every pair of consecutive digits has a difference of one is called a step number.
A pandigital number contains every decimal digit from 0 to 9 at least once.
How many pandigital step numbers less than 10^40 are there? 
*/

public class Problem178
{
    [Memoize]
    step(cur : int, len : int, bits : int) : Int64
    {
        match (len - 1, bits %| (1 << cur))
        {
        | (0, 0x3ff)  => 1L
        | (0, _)      => 0L
        | (len, bits) =>
            def rec(cur)
            {
            | _ when cur < 0 || cur > 9 => 0L;
            | _ => step(cur, len, bits)
            }
            rec(cur + 1) + rec(cur - 1)
        }
    }

    public Solve() : string
    {
        $[1..40]//max 66
        .Map(len =>
        {
            $[1..9]
            .Map(s => step(s, len, 0))
            .Sum64()
        })
        .Sum64()
        .ToString()
    }
}

А в этом случае макрос [Memoize] превращает алгоритм из экспоненциального в линейный.
Сколько времени нужно просить автора D чтобы он добавил [Memoize]?

E>В Sign# есть, в D есть, в Nice есть такие же контракты. И команды там были не на много больше, чем у Nemerle.

Те контракты что в немерле сделаны чисто по приколу.
Если они тебе не нравятся ты можешь сделать правильные контракты.
Это тебе позволяет микроядро и метапрограммирование.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: C++0x начали урезать
От: Трурль  
Дата: 05.02.08 10:24
Оценка: 36 (1) +1
Здравствуйте, eao197, Вы писали:

E>Я таки услышу ответ на вопрос о том, к пределу какой сложности приближается разработка современных языков программирования?

Я по секрету сознаюсь, что этот компилятор с Модулы уже на пределе допустимой сложности, и я бы чувствовал себя совершенно неспособным создать хороший компилятор для Ады.
Н. Вирт

Re[10]: C++0x начали урезать
От: WolfHound  
Дата: 12.11.07 10:12
Оценка: 7 (1) +1
Здравствуйте, vdimas, Вы писали:

V>Это просто семафор со счётчиком = 1

V>Вроде так он и реализован в винде,
Не совсем.

HANDLE CreateEvent(
  LPSECURITY_ATTRIBUTES lpEventAttributes, 
  BOOL bManualReset, 
  BOOL bInitialState, 
  LPTSTR lpName 
);


bManualReset
[in] Boolean that specifies whether a manual-reset or auto-reset event object is created. If TRUE, then you must use the ResetEvent function to manually reset the state to nonsignaled. If FALSE, the system automatically resets the state to nonsignaled after a single waiting thread has been released.


ИМХО выделеное с семафором не стыкуется.

Причем устанавливать и сбрасывать событие можно по настроению.
Например в винде есть пара забавных event'ов
\KernelObjects\HighMemoryCondition
\KernelObjects\LowMemoryCondition
Используются системами с активнам управлением памятью например: MS SQL, .NET

V>т.е. если будет примитив-семафор, то все остальные делаются тонкой прослойкой в либе.

Теоритически да. Но приктически решение будет так себе.
Особенно если вспомнить про различные lock-free структуры данных.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[54]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.02.08 13:31
Оценка: 6 (1) -1
Здравствуйте, VladD2, Вы писали:

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


E>>Попробуйте довести Nemerle хотя бы до такого состояния.


VD>До какого? Уж судьбу Эфила я бы никому не пожелал.


Просто для информации: по словам Мейера, сейчас EiffelStudio -- это больше 2M строк на Eiffel (наверное, сюда входит еще и EiffelVision2 (кросс-платформенная графическая библиотека) и EiffelBuild (GUI дизайнер)). Всего EiffelStudio (опять же по словам Мейера) была продана в количестве десятков тысяч копий (причем каждая копия стоит значительно дороже $1000).

А теперь вопрос: ты не пожелаешь Nemerle иметь проекты такого масштаба, объемы продаж которых будут исчисляться десятками тысяч копий?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: C++0x начали урезать
От: FR  
Дата: 13.12.07 17:22
Оценка: 2 (1) +1
Здравствуйте, VladD2, Вы писали:

VD>Там не только вывод типов. Там еще и система типов с возможностями остуствующими в С++ есть. А вывод типов дает урощение кода и уменьшение его объема. В некоторых задачах, особенно связанных с анализом и распознаванием, можно получить до 10 раз. Уж в 2-3 раза код будет точно меньше.


Вот тут http://www.cminusminus.org/rsync/dist/lua-ml-20071123.tar.gz лежит интерпретатор Lua 2.5 написанный на Ocaml, тут он же http://www.lua.org/ftp/lua-2.5.tar.gz на си, и почему то сишная версия поменьше в размерах

С (*.с *.h) 194 kb
Ocaml (*.nw) 222 kb

(я еще не копался что там внутри так что если кто раскопает и разъяснит почему буду рад)
Re[22]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 14.12.07 18:25
Оценка: 2 (1) +1
Здравствуйте, konsoletyper, Вы писали:

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


K>Можно про выделенное подробнее? Желательно, ссылки...


Inferno & Plan 9?
now playing: Braincell — Cognition
Re[39]: C++0x начали урезать
От: Трурль  
Дата: 06.02.08 11:51
Оценка: 2 (2)
Здравствуйте, EvilChild, Вы писали:

EC>Здесь видимо уместно задать вопрос: какую сложность автор считает допустимой?


Примерно так:

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

Re[22]: C++0x начали урезать
От: FR  
Дата: 19.12.07 14:57
Оценка: 1 (1) +1
Здравствуйте, VladD2, Вы писали:

VD>Я считаю, что косяки лучше не допускать. Тот же Немерле проектировался с нуля и без компромисов для (скажем) совместимости с С.


У немерле тоже есть компромиссы из-за совместимости с NET

VD>С++ можно сделать удобным только если таки отказаться от совместимости. Я бы тупо ввел два режима. 1. Режим совместимости в ктором все по старому. 2. Режим 0х в котором многое запрещено и не допустимо, но зато обеспечивается полноценный контроль. Первое что я бы запретил — это препроцессор. Второе — использование указателей. Третье — программироание шаблонов без концептов.


Проще написать новый язык, жаль Вальтер не торопится
Re[35]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.02.08 16:00
Оценка: 1 (1) :)
Здравствуйте, eao197, Вы писали:

E>Тогда нужно определиться в критерии "иметь будущее". Если под этим понимается "стать мейнстримом", то это одно, а если "применяться кое-где" -- то совсем другое.


E>Lisp мейнстримом не стал.


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

Лисп действительно сложен для постижения и реального применения. К тому же он варился в очень обособленной среде. Одно время "обычными" программистами считалось, что этот язык пригоден только для обработки списков и работ в области ИИ. Потом у Лиспа появилось море диалектов. Потом появился ДОС под которым интерпретаторы были не в почете, а компиляторов приличных не было. Да и сейчас найти приличную реализацию компилирующего Лиспа в купе с IDE не просто. Емаксы это все же не для мэйнстрима.

Немерле же имеет одну особенность. Он практически является сабсэтом C#-а. А уж для него налажено обучение по полной программе.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[50]: C++0x начали урезать
От: FR  
Дата: 06.02.08 08:28
Оценка: 1 (1) +1
Здравствуйте, Andrei F., Вы писали:

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


E>>А кстати, где именно Брайт поставил перед собой такую задачу? Где он декларировал, что D является непосредственной заменой C++?


AF>Читаю например результаты поиска в гугле и вижу в первой же ссылке:

AF>Compiled, garbage collected, simpler C/C++ replacement

Ты не там ищешь проблемы у D.
Основная проблема в том что автор не может остановится. Перестать добавлять фичи и выпустить нормальный твердый релиз. Фич уже вполне достаточно. Меня, и думаю большинство тех кому D симпатичен, от его серъезного использования останавливает только это.
Если язык стабилизируется будут и обертки к C++ и будут библиотеки. Просто задача сделать обертки к C++ типа SWIG или на шаблонах (типа boost::python) вещи достаточно объемные и надо сейчас очень сильно рисковать чтобы сейчас начинать такое.
Re[7]: C++0x начали урезать
От: Cyberax Марс  
Дата: 07.12.07 18:53
Оценка: +2
Здравствуйте, VladD2, Вы писали:

C>>Как в C++/CLR, например. Который, кстати, остается единственным

C>>нормальным языком, где сделана интероперабельность между GC и ручным
C>>управлением памятью.
VD>Дык там тупо сделали два языка. Один С++, а другой не очень.
Ага. Но там хотя бы как-то продумали механизм их совмещения (чего не скажешь о D, например).
Sapienti sat!
Re[4]: C++0x начали урезать
От: Andrei F.  
Дата: 08.12.07 05:29
Оценка: -1 :)
Здравствуйте, BulatZiganshin, Вы писали:

BZ>меня точно так же удивляют преданные пользователи языков без автоматического полиморфизма, т-ех, где надо явно писать типы, нет лямбд и не поддерживается point-free programming style


Я немного не про это говорил...
Re[5]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.12.07 11:25
Оценка: +1 -1
Здравствуйте, Nuzhny, Вы писали:

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


Не смешно, не смейся. Кто же тебя просит?
Другм вот смешно, как видишь.

N>здесь множество xxx
Автор: VladD2
Дата: 17.10.05
. Теперь шестнадцатеричный префикс...


Почему теперь, то? Вот в приведенной тобой ссылочке тоже этот вариант описан. Причем сообщение датируется 2005-ым годом. Сейчас уже почти 2008-ой, а стандартом так и не пахнет. Но труд даром не пропадает. Некоторые разумные идеи из него уже воплощены в C# 3.0.

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

История с новым стандартом С++ уже давно стала шуткой юмора. А вы все обижаетесь когда о нем в саркастическом тоне говорят.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: C++0x начали урезать
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 12.12.07 13:30
Оценка: +2
А как же скорость? Куча вычислений, многократные проходы по изображению, получение видео от WDM-драйверов, работа с DirectDraw поверхностями... Слава богу, что с новыми процессорами постепенно из кода ассемблерные вставки убираются.
С С++ всё понятно. На нём (и на С ещё) такие задачи решались и решаются. И библиотек на нём много — те же интеловские OpenCV и IPP.

Просматривая всякого рода тесты по быстродействию кода на .Net того же C#'па, у меня сложилось не очень благоприятное впечатление. А ОКамл где потом специалистов на нём искать?
Re[13]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 13.12.07 17:39
Оценка: -1 :)
Здравствуйте, FR, Вы писали:

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


VD>>Там не только вывод типов. Там еще и система типов с возможностями остуствующими в С++ есть. А вывод типов дает урощение кода и уменьшение его объема. В некоторых задачах, особенно связанных с анализом и распознаванием, можно получить до 10 раз. Уж в 2-3 раза код будет точно меньше.


FR>Вот тут http://www.cminusminus.org/rsync/dist/lua-ml-20071123.tar.gz лежит интерпретатор Lua 2.5 написанный на Ocaml, тут он же http://www.lua.org/ftp/lua-2.5.tar.gz на си, и почему то сишная версия поменьше в размерах


FR>С (*.с *.h) 194 kb

FR>Ocaml (*.nw) 222 kb


А мне вот это
Автор: remark
Дата: 01.01.07
очень понравилось.
Визуально вроде код на С на несколько вспомогательных строчек длиннее, но по сути один в один с Немерле.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[14]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 10:24
Оценка: -1 :)
Здравствуйте, WolfHound, Вы писали:

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


FR>>С (*.с *.h) 194 kb

FR>>Ocaml (*.nw) 222 kb
FR>>(я еще не копался что там внутри так что если кто раскопает и разъяснит почему буду рад)

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


Это наталкивает на мысли...


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[22]: C++0x начали урезать
От: jazzer Россия Skype: enerjazzer
Дата: 19.12.07 14:25
Оценка: +2
Здравствуйте, VladD2, Вы писали:

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


J>>Естественно, иначе весь существующий код без концептов перестанет компилироваться.

VD>Ага.

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


VD>Я считаю, что косяки лучше не допускать.

Можно подумать, кто-то считает иначе.

VD>Тот же Немерле проектировался с нуля и без компромисов для (скажем) совместимости с С.

Это он сейчас так проектировался.
А вот когда ему стукнет 20 лет, как С++, тогда ему придется обеспечивать прежде всего совместимость с самим собой, если, конечно, он собирается эволюционировать.

VD>С++ можно сделать удобным только если таки отказаться от совместимости.

Ну мне лично совместимость никак не мешает.

VD>Я бы тупо ввел два режима. 1. Режим совместимости в ктором все по старому. 2. Режим 0х в котором многое запрещено и не допустимо, но зато обеспечивается полноценный контроль. Первое что я бы запретил — это препроцессор. Второе — использование указателей. Третье — программироание шаблонов без концептов.


А, ну опций компиляции можно завсегда придумать вагон, с этим никто и не спорит.
Ты и сейчас можешь, скажем, запускать gcc с максимальным уровнем варнингов и в pedantic mode, в котором он пишет кучу варнингов, и при этом еще одним флажком сказать, что все варнинги — это ошибки — и получишь примерно то же — запрет всех показавшихся компилятору опасными конструкций.

Или там пользоваться каким-нть линтом, который ловит "опасный" код и имеет кучу опций по этому поводу, а с выходом С++Ох их станет еще больше.

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

Двумя режимами точно никто не обойдется, потому что выбрасывать весь старый код ради того, чтоб заюзать одну новую фичу, абсолютно бессмысленно. И не юзать фичу ради сохранения старого кода столь же бессмысленно. А посему никто не будет делать подобных "или-или" режимов — ими просто никто не будет пользоваться.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[25]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.07 15:57
Оценка: -2
Здравствуйте, jazzer, Вы писали:

J>Не надо никому из пишущих на С++. Ты, очевидно, к ним не относишься.


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

J>Если это будет соответствующим образом гранулироваться — я только за. И, опять же, совсем не 2 режима (все или ничего), а отдельное управление каждой "опасной" фичей.


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

Вот только у С++-ных комитетчиков мозг сварился много лет назад. Они даже не будут думать подоным образом (к сожалению). Они тупо свалят все в кучу и в 0х будут только расширения которые просто добъют язык увеличением сложности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: C++0x начали урезать
От: Константин Л. Франция  
Дата: 10.01.08 09:59
Оценка: +1 -1
Здравствуйте, minorlogic, Вы писали:

[]

M>К сожалению в плюсах шаблоны изначально криво встроенны , и Concepts эти слабая попытка лечения. А вылечить концептальные проблемы скорее всего не получится.


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

Меня иногда коробит "концептность" .net generics.
Re[26]: C++0x начали урезать
От: Andrei F.  
Дата: 17.01.08 17:15
Оценка: -2
Здравствуйте, VladD2, Вы писали:

VD>Надо было ввести один делегат и передавать фукнции конвертации куда нужно по ссылке.


И если в генерик-типе нужна конвертация, то этот делегат придется добавить в каждый конструктор, и писать его в каждом вызове оператора new. Спасибо, не надо такой радости.
Re[30]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.02.08 06:05
Оценка: +2
Здравствуйте, Andrei F., Вы писали:

AF>Это вероятное будущее для динозавров вроде D и ему подобных. И даже не вероятное, а практически гарантированное.

AF>А настоящее будущее — за Немерле или другими языками, которые будут устроены по тому же принципу.

Мосье оракул?

А языки типа Scala или Nice вы куда вписываете?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[70]: C++0x начали урезать
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 07.02.08 08:47
Оценка: -2
Здравствуйте, WolfHound, Вы писали:
WH>В немерле полные по Тьюрингу имеющие доступ ко всему API компилятора макросы.
WH>Те при особом жилании на них можно сделать практически все.

Это не верно просто потому, что эти макросы не работают в run-time.
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[60]: C++0x начали урезать
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 07.02.08 10:11
Оценка: +2
Здравствуйте, WolfHound, Вы писали:

L>>continuations — это call/cc. Нарисуй его, пожалуйста. Как решить частные случаи, которые решает call/cc, не особо интересно. Вопрос был о поддержке продолжений.


WH>Покажи случай который не делается через yield. Тебе это должно быть не трудно.


1. Сам примитив call/cc. Я хочу, чтобы мои вычисления не знали о том, что они используются как продолжения.
В принципе, если yield является first-class order, то этого должно быть достаточно.

2. Классический оператор amb. В частности, пример с (if (amb #t #f) 1 (amb)) в котором amb обязан возвращать #t.

3. call/cc легко использовать как исключение, а yield? Смысла для основной канвы спора имеет мало, т.к. исключения уже есть, но для того, чтобы придраться к словам "Покажи случай который не делается через yield" можно

4. shift/reset примитивы

5. То, что вытворяет Олег Киселёв даже просить не буду

На самом деле всё это совершенно неважно. call/cc мощнее yield, так как он позволяет сделать то, что делает yield, а yield не позволяет сделать то, что делает call/cc. Только в отрыве от языка это мало что значит.

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

L>>Мультиметоды — зло, хотя бы по той причине, что их нет в Немерле

WH>Я уже сказал чем плохи мультиметоды.
WH>Если ты скажешь как разрешить их противоречия я их без проблем сделаю.

Да нет, мне это не особо интересно. Просто разговор позабавил

— на макросах можно сделать всё
— сделай мультиметоды!
— мультиметоды — зло

L>>На самом деле тут о чём разговор? О том, что если макросы есть, то всё — можно уже не расширять язык или что?

WH>По большей части да. По крайней мере в той что любит крутиться Aлександреску.
WH>Что касается всего остального то тут больше вопросов чем ответов.
WH>Например ленивость по умолчанию мягко говоря сомнительна.
WH>Хотя при жилании можно сделать и болие общую ленивость что уже сделана вопрос лишь в том, а оно надо?

Про ленивость по умолчанию вроде как никто не говорил — это вообще вопрос выбора, спорить тут не о чем. Прочее — это, по моему, отголоски дискуссии о том, что макросы — это индикаторы недоделок в языке. Так что на макросы можно смотреть и с другой стороны — если макросы есть, значит есть что расширять
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[56]: C++0x начали урезать
От: Klapaucius  
Дата: 07.02.08 13:02
Оценка: +2
Здравствуйте, WolfHound, Вы писали:

AF>>>С трудом представляю, что можно менять в ядре, тем более — постоянно

FR>>Я думаю просто нужно чтобы Aлександреску заинтересовался Немерле
WH>Он ничего не придумает.
WH>Да и что можно придумать если уже есть полные по Тьюрингу макросы?

Как сделать классы типов на макросах?
... << RSDN@Home 1.2.0 alpha rev. 774>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[57]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 15:53
Оценка: -2
Здравствуйте, FR, Вы писали:

FR>Даже я могу кучу вещей придумать в которых полные по тьюрингу макросы мало чем помогут, например добавь подержку продолжений ( http://en.wikipedia.org/wiki/Continuation ), или мультиметов в стиле CLOS, или нормальную ленивость, думаю в этот список можно еще немало вещей добавить и со временем список будет только расти.


Все это реализуется (если уже не реализовано) на макросах. Так что просто кончай сотрясать воздух.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[66]: C++0x начали урезать
От: FR  
Дата: 07.02.08 18:28
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

VD>Что ты вообще сказать то хочешь этими примерами? Что макросы не всесильны? Ну, это езжу понятно. От этого что-то меняется?


Я просто тихо мирно именно это и сказал, что макросы не всесильны. Из-за чего WolfHound вцепился в меня мертвой схваткой
Re[69]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 07.02.08 19:13
Оценка: +2
Здравствуйте, FR, Вы писали:

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


FR>Файберы тоже частный случай.


Я так понимаю это Влад coroutines имеет в виду, которые, вроде тоже частный случай.
now playing: Autechre — plyPhon
Re[42]: C++0x начали урезать
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 07.02.08 21:05
Оценка: +2
Здравствуйте, VladD2, Вы писали:

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


VD>Это личное мнение, а не обоснование. Мое мнение, что дело в тех кто учит.


Может быть. Мне труднее учить ФП, чем было ООП.

Если дело в нас, то открой секрет, как же учить надо? Ну или скажи, что ты под ФП понимаешь, ну то есть, что ты учил?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[50]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.02.08 05:55
Оценка: -1 :)
Здравствуйте, VladD2, Вы писали:

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


E>>Собственно, против этого я и не спорил (по крайней мере здесь ). Изначально я хотел узнать, почему это будущее есть только у языков, построенных по принципу Nemerle.


VD>А чего тогда осбуждашь совсем другое?


Потому, что Andrei.F так и не смог обосновать свою точку зрения.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[65]: C++0x начали урезать
От: Andrei F.  
Дата: 08.02.08 10:13
Оценка: +1 -1
Здравствуйте, FR, Вы писали:

FR>На таком уровне с D тоже получится, каких то принципиальных ограничений не видно.


даже и близко не получится
Re[47]: C++0x начали урезать
От: WolfHound  
Дата: 08.02.08 11:52
Оценка: +2
Здравствуйте, eao197, Вы писали:

E>Если уж разработчики Nemerle с их гениальными идеями не смогли это сделать, то я даже и пытаться не буду.


Я ща начну разговаривать в стиле колхоза...
Я начинаю его понимать...

E>Я уже пытался объяснять про проблемы совместного использования нескольких разных синтаксических макросов с одинаковыми ключевыми словами. Но вам выгоднее не обращать на них внимания. Хотя как раз в этом отличие между макросами и библиотеками и состоит -- в отсутствии конфликтов.

Не делай using и используй макрос как вызов функции. Делов то.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[48]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.02.08 13:59
Оценка: -2
Здравствуйте, WolfHound, Вы писали:

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


E>>Ты серьезно думаешь, что реализация на Nice на порядки сложнее таковой в Nemerle?

WH>Да.
WH>То что я привел полный код макроса ensures.

То, что я привел, содержит не только код макроса ensures, но и макроса requires, а так же код, отвечающий за pretty-print этих вещей.

WH>Если бы не уродская система типов .NET'а (в данном случае пакостит тип void) то макрос был бы еще короче.

WH>Добавление old туда добавит еще строк 5-10.

Есть у меня подозрения, что это будет не совсем так.

WH>И это при том что этот макрос опциональный и его добавление/удаление не влияет на ядро компилятора вобще. Те совсем никак.

WH>Болие того этот макрос вполне могли написать посторонние люди, а авторы компилятора просто заапрувить.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[58]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.08 18:03
Оценка: +1 :)
Здравствуйте, WolfHound, Вы писали:

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


E>>Вот, надоело сегодня целый день документацию писать, решил душу отвести. В самом примитивном виде memoize на D2.0 выглядит так (наверное, что-то похожее можно и на D1.0 сделать):

WH> Надеюсь ты сам понимаешь насколько это решение ущербно по сравнению с оригинальным макросом.

А где ты видел решение? Это просто доказательство того, что memoize на D2.0 сделать можно. Более того, и решение твоей задачки 192 с его помощью получится.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[73]: C++0x начали урезать
От: Andrei F.  
Дата: 12.02.08 08:03
Оценка: -1 :)
Здравствуйте, eao197, Вы писали:

E>Дело не в формулировках, дело в конкретных примерах. Вызов методов crypto++ из D это одно, использование ACE_Reactor -- другое, а размещение на формочке в VB ActiveX элемента -- третье. Хотя везде legacy-код и везде интероперабильность. Так что примеры хотелось бы услышать.


Конкретные примеры есть в MSDN, с подробным описанием что можно сделать и как. Что еще нужно?
Re[4]: C++0x *крик души*
От: jazzer Россия Skype: enerjazzer
Дата: 23.02.08 03:38
Оценка: :))
Здравствуйте, kov_serg, Вы писали:

_>Видимо термин злое%&чий вызвал такую реакцию. Но это не мат.


Надо же, каждый день что-то новое узнаешь...
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[7]: C++0x *крик души*
От: VoidEx  
Дата: 24.02.08 14:27
Оценка: +1 :)
Здравствуйте, kov_serg, Вы писали:

C>>>>http://en.wikipedia.org/wiki/C%2B%2B0x#Thread-local_storage ?

_>>>И еще докле мы будем в качестве конструктора и деструктора писать имя класса???? почему нельзя зарезервировать имена типа ctor и dtor???
C>>А зачем?
_>Сам подумай. Тебе надо поменять название класса. Тебе приходиться менять имена во многих местах. Просто нелогично и не удобно. И потом наличие пред деструктора и после конструктора особенно как виртуальных функций было бы замечательным явлением, но это мечты.

Еще предлагаю ввести base0, base1, base2... А лучше сразу base(0), base(1)...
Это для списка инициализации в случае множественного наследования, если кто не понял. Да и просто к базовым обращаться. Остается еще одна проблема — а если поменяют местами базовые в списке? Ну т.е. было public A, public B, а сделали public B, public A. Блин, тут есть над чем серьезно подумать!
Re[35]: C++0x начали урезать
От: Andrei F.  
Дата: 01.02.08 13:02
Оценка: 70 (1)
Здравствуйте, eao197, Вы писали:

E>Lisp мейнстримом не стал. Хотя тогда его синтаксис вряд ли был камнем преткновения -- выбирать-то было особо не из чего. И даже знаменитого C-шного синтаксиса, который сейчас является чуть ли не ключем к успеху языка, тогда еще не было. Так что причина неудачи мейнстримовых притязаний Lisp-а в неудобном синтаксисе не выглядит очень убедительной. Скорее это отговорка для тех, кто не может перестроиться на другую волну.


Когда Лисп только появился, он просто слишком опередил свое время и практикам был не особо то и нужен. А вот уже потом его синтаксис (точнее — его отсутствие) сделал свое злое дело.
Можно сколько угодно придумывать про "другую волну", "концептуальную правильность" и так далее. Но писать x+y*z все равно было и будет удобнее, чем (+ x (* y z)), или как там оно в Лиспе пишется.

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


А что плохого, что они их создают? С таким же успехом можно сказать "язык Х не имел никакого успеха, потому что Х-еры склонны создавать свои библиотеки под собственные задачи"

E>И эта причина находит свое подтверждение в том, что мейстримами (по крайней мере в последние 15 лет) были как раз языки, очень ограничивающие программистов в возможностях изменения языка под себя. А это как раз основная фича Nemerle.


"После этого — значит, вследствие этого". Типичная логическая ошибка.

E>Если же под будущим понимать просто существование в каких-либо нишах (как это сейчас с Lisp-ами и Schema-ми происходит), то почему тогда у D и иже с ним нет будущего? Местами я бы сам с удовольствием использовал бы D вместо C++. И мне кажется, вы не представляете себе, какой прогресс в действительности происходит вокруг D, насколько он обрастает всякой всяченой.


Пока не будет удобного и надежного интеропа с другими языками (как минимум — тем же С++), D так и будет оставаться игрушкой для фанатов. Да и ниша самого С++ постоянно уменьшается.

E>И еще один экскурс в историю -- в начале 2000-ных у Ruby так же не было будущего. Это был просто еще один скриптовый язык, мало кому известный и мало кем используемый. Таковым он и оставался года до 2005-го. Зато как все изменилось за последние несколько лет!


А что такого случилось? На первый взгляд, он так и остался еще одним скриптовым языком, только чуть более известным, чем раньше

E>Пределу сложности чего?

E>Современные языки сложно разрабатывать? На примере чего это видно? Разве были жалобы от Хальсенберга о том, что они C# 3.0 делали на пределе возможностей? Или может быть Одерски заявил, что они больше не в состоянии развивать Scala? Что-то не припомню такого, наоборот, релизы языка выходят с завидной стабильностью и переодичностью.

E>Или может речь идет о пределе сложности восприятия языка пользователем? Мол столько фич насовали в язык, что мало кто способен с ними разобраться. Так а чем Nemerle здесь лучше?


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

E>Все когда-то происходит в первый раз.


Нет, не всё. Некоторые вещи происходят в первый раз. А некоторые — никогда.

E>Или "сделал все, что хотел, теперь нужно посмотреть, нужно ли это вообще кому-то".


Проект, который не развивается, точно никому не будет нужен.

E>Да посмотрите. А то по вашим словам Nice очень похож на Scala. Хотя из похожести там только похожий набор ключевых слов: let, var, class, for, ...


А какие принципиальные отличия?
Re[57]: C++0x начали урезать
От: FR  
Дата: 11.02.08 18:12
Оценка: 38 (1)
Здравствуйте, eao197, Вы писали:


E>- static memory объявлено только для простоты. По хорошему надо бы иметь асоциативный вектор созданных делегатов, в котором ключем будет аргумент dg. Ну и защитить его семафором для поддержки многопоточности;


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

E>- корявый код с использованием структуры Key и foreach-а для заполнения объекта k нужен из-за особенностей реализации D-шных туплов. Объявить тупл в качестве типа ключа в ассоциативном массиве в D можно, а вот задействовать реально его в качестве ключа у меня не получилось. Тут либо я идиот, либо действительно лыжи не едут;


Угу, туплы корявы и слабоваты, их лучше бы на уровне языка подержать, а ни как сейчас, плюс добавить легкое получение аргументов функций в виде тупла.
Re[18]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.07 15:55
Оценка: 4 (1)
Здравствуйте, Дьяченко Александр, Вы писали:

ДА>Можно вопрос немного в сторону выделенное нельзя разве записать покороче с использованием квазицитирования?

ДА>Хотя бы
TExpr.Literal(Literal.Bool(true))
замениить на
<[ true ]>

ДА>?

В Немерле квази-цитирование доступно только для PExpr, а Вольфхаунд использовал TExpr. И вообще, я думаю, что это просто пример.

Да и что тут говорить о таких высших материях как квази-цитирование если ставится под сомнения ползность базовых вещей вроде вариантов и паттернм-матчинга? Квази-цитирование основано на них и без них оно будет просто не полноценно.

К тому же я уверен, что аппоненты даже не понимаю как выглядит разбор и конструирование кода с искользованием квази-цитирование. Это просто другой уровень мышления.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.12.07 16:01
Оценка: 4 (1)
Здравствуйте, Дьяченко Александр, Вы писали:

ДА>Это кусок патча компилятора в файле ILEmitter который ты приводил в другой ветке (см. Re[11]: Принцип подстановки Барбары Лисков
Автор: VladD2
Дата: 01.01.07
ближе к концу).


Преобразование из PExpr в TExpr — это типизация. При этом нужно сначала типизировать все внешние ссыдки. Обычно типизируется тело метода. В общем, это не самый простой и короткий рассказ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[59]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:13
Оценка: 4 (1)
Здравствуйте, EvilChild, Вы писали:

EC>Эта штука макросами реализована? Я про yield.


На половину. Сам код в компиляторе, но используется макросистема и ее АПИ. В приципе можно было бы и макросом залудить. Тут важна сама возможность анализировать фунцию и генерировать иной ее код. Эта возможность есть. Просто будучи реализованным на макросах синтаксис был бы иной. Например:
[Yield]
public MapFilteredLazy[T, U](this lst : list[T], fn : T -> option[U]) : SCG.IEnumerable[U]
{
    def loop(_)
    {
        | head :: tail =>
            match (fn(head))
            {
            | Some(result) => yield result;
            | None => ();
            }
            loop(tail);
        | [] => ();
    }
    loop(lst);
}
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[61]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:13
Оценка: 4 (1)
Здравствуйте, EvilChild, Вы писали:

EC>Можешь пояснить, что этот код делает?


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

EC> То же, что и ранееприведённый?


А, ты о результате? Да.

EC> Зачем атрибут [YieldSupport] установлен?


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

EC>И почему yield не макросом сделан?


По больше части как раз чтобы не иметь такого синтаксиса. Сама реализация делается через макро-АПИ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: C++0x начали урезать
От: WolfHound  
Дата: 14.12.07 18:16
Оценка: 2 (1)
Здравствуйте, konsoletyper, Вы писали:

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

K>Можно про выделенное подробнее? Желательно, ссылки...
http://en.wikipedia.org/wiki/Limbo_(programming_language)
И дальше по ссылкам.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.07 13:25
Оценка: 1 (1)
Здравствуйте, FR, Вы писали:

FR>Еще здесь есть неплохие картинки показывающий размер кода (притом оптимизированного на скорость) для разных языков, правда там не компиляторы, а более общий код, что для меня интересней. Разница между ML образными и C++ как раз в полтора — два раза.


1.5 — это если очень тупить на ML-еподобном языке и если очень окуратно писать на С. С++ обычно еще больший оверхэд добавляет, так как классы для компиляторов это перебор.
А вот если задача сложная (настоящий компилятор) и все наоборот (тупят на С++ и акуратно пришут на клонах ML), то разрыв может достигать и 10 раз.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: C++0x начали урезать
От: FR  
Дата: 17.12.07 05:49
Оценка: 1 (1)
Здравствуйте, Стэн, Вы писали:

С>А теперь от задач абстрактных, к задачам конкретным. Сейчас я занимаюсь разработкой библиотеки асинхронного программирования act-o
Автор: Стэн
Дата: 27.11.07
. На данный момент она написана на C++ и используется только из C++. Не касаясь вопроса о том, что писать клиентские приложения на C++ — некошерно, обратимся к вопросу на чем писать runtime? Для новых эксперементальных runtime'ов я решил отказаться от С++ и писать на чистом C, так как он проще и дров наломать в нем сложнее... В связи с моральным устареванием С, как несколько раз я читал в этой теме, у меня вопрос — есть ли ему какая-то замена? Но только, чтобы программы компилировались в native-код, чтобы был полный и простой доступ к низкоуровневым API ОС и железу, чтобы программы получались быстрыми, и чтобы была возможность относительно легко портировать программы на разные ОС.


1) Modula — Oberon.
2) Forth
3) Кроме того есть вариант своего DSL или кодогенератора который генерирует код на си или например на http://www.cminusminus.org/
Re[33]: C++0x начали урезать
От: Andrei F.  
Дата: 01.02.08 06:56
Оценка: 1 (1)
Здравствуйте, eao197, Вы писали:

E>И какие данные? Учитывается ли опыт Lisp-ов?


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

E>Доказательство по аналогии...


Это не доказательство, это просто аналогия. Для иллюстрации.

E>Тем не менее хотелось бы услышать более конкретные причины, по которым у Scala нет будущего.


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

E>В Nice автор реализовал все, что хотел.


Никогда не встречался с таким в жизни. Всегда есть что-то еще, что хочется добавить и улучшить. Скорее всего, причины другие — "сделал всё, что смог" или "просто надоело"
Хотя надо будет изучить этот язык повнимательнее, вдруг там есть что-то интересное.
Re[37]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.02.08 16:25
Оценка: 1 (1)
Здравствуйте, FR, Вы писали:

VD>>Немерле же имеет одну особенность. Он практически является сабсэтом C#-а. А уж для него налажено обучение по полной программе.


FR>А плюс ли это вообще?


Несомненно плюс. Если конечно нет дикого желания во всем видеть минсв.

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


Тут есть два соображения:
1. Объем знаний требуемый для использования ФП сильно приувеличен. Просто учить ему не умеют. Раньше ФП учили близкие к математике и вообще науке люди. Резльтат получался плачевным. Из простешей вещи они сразу же учудили мозголомство.
2. В том то и дело, что если знать Шарп (а таких программистов очень много), то фунциональные вещи осваиваются довольно легко и, что не маловажно, прямо во время работы над каким-нибудь проектом. Желательно только чтобы при этом рядом с новичком работал кто-то кто уже прошел этот пукть и может потихоничку направлять новичка в нужное русло.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[56]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.08 16:31
Оценка: 1 (1)
Здравствуйте, WolfHound, Вы писали:

WH>2)Эта штука будет различать static и instance методы?

WH>3)А можно таки посмотреть на этот самый шаблон memoize?

Вот, надоело сегодня целый день документацию писать, решил душу отвести. В самом примитивном виде memoize на D2.0 выглядит так (наверное, что-то похожее можно и на D1.0 сделать):
import std.stdio;

R delegate(U) memoize(R, U...)( R function(U) gd )
    {
        struct Key {
            U m_u;
        }
        static R[Key] memory;
        R inner( U u )
            {
                Key k;
                foreach( i, a; u )
                    k.m_u[ i ] = u[ i ];
                R * p = (k in memory);
                if( p !is null )
                    return *p;
                else
                    {
                        R r = gd(u);
                        memory[ k ] = r;

                        return r;
                    }
            }

        return &inner;
    }

int sum( int a, int b )
    {
        writefln( "a=", a, ",b=", b );
        return a + b;
    }

void main()
    {
        auto m = memoize( &sum );
        writefln( m( 1, 2 ) );
        writefln( m( 1, 2 ) );
        writefln( m( 3, 2 ) );
        writefln( m( 2, 1 ) );
        writefln( m( 2, 1 ) );
        writefln( m( 1, 2 ) );
        writefln( m( 3, 2 ) );
    }


При запуске выдает:
a=1,b=2
3
3
a=3,b=2
5
a=2,b=1
3
3
3
5


Небольшие замечания по коду:
— static memory объявлено только для простоты. По хорошему надо бы иметь асоциативный вектор созданных делегатов, в котором ключем будет аргумент dg. Ну и защитить его семафором для поддержки многопоточности;
— корявый код с использованием структуры Key и foreach-а для заполнения объекта k нужен из-за особенностей реализации D-шных туплов. Объявить тупл в качестве типа ключа в ассоциативном массиве в D можно, а вот задействовать реально его в качестве ключа у меня не получилось. Тут либо я идиот, либо действительно лыжи не едут;
— ну и, наверное, потребуется продублировать вариант memoize для случая, когда dg является не функцией, а делегатом. Но здесь, возможно, дублирование можно будет сделать через mixin-ы.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: C++0x начали урезать
От: Cyberax Марс  
Дата: 12.11.07 09:23
Оценка: :)
igna wrote:
> C> С Boost/ACE я хотя бы знаю, что оно себя одинаково вести себя везде
> будет.
> Это да. TAO 1.4a (ACE 5.4) при компиляции в Visual Studio 6.0 совершенно
> одинаково, то есть независимо от установленного SP3, SP5 или SP6,
> приводит к аварийному завершению при закрытии Visual Studio.
Ну это глюки древних компиляторов — сколько уже можно мучать VS6?
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[5]: C++0x начали урезать
От: Cyberax Марс  
Дата: 07.12.07 15:10
Оценка: +1
VladD2 wrote:
> C>Только консервативный (т.е. мегахак).
> А как ты вообще видишь себе прикручивание точного ЖЦ к языку
> допускающему небезопасные операции с памятью и в котором отсуствуют
> такие примитивы как массивы?
Как в C++/CLR, например. Который, кстати, остается единственным
нормальным языком, где сделана интероперабельность между GC и ручным
управлением памятью.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[6]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.12.07 16:31
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

C>Как в C++/CLR, например. Который, кстати, остается единственным

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

Дык там тупо сделали два языка. Один С++, а другой не очень.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: C++0x начали урезать
От: vdimas Россия  
Дата: 10.12.07 08:48
Оценка: -1
Здравствуйте, WolfHound, Вы писали:



WH>bManualReset

WH>[in] Boolean that specifies whether a manual-reset or auto-reset event object is created. If TRUE, then you must use the ResetEvent function to manually reset the state to nonsignaled. If FALSE, the system automatically resets the state to nonsignaled after a single waiting thread has been released.
WH>[/q]

WH>ИМХО выделеное с семафором не стыкуется.


Что именно не стыкуется? Классический семафор именно вручную и устанавливается, как иначе? Установка этого семафора — это сброс самого события. Этот автосброс можно сделать одной лишней строчкой кода-обёртки.


V>>т.е. если будет примитив-семафор, то все остальные делаются тонкой прослойкой в либе.

WH>Теоритически да. Но приктически решение будет так себе.

Еще раз, все примитивы синхронизации делаются на семафорах, принципиально, а те, в свою очередь, на атомарных операциях инкремента/декремента. Например, открыты для доступа и изучения CRITICAL_SECTION в винде, полюбопытствуй. Мютекс (коим является и CriticalSection) — это структура из семафора и идентификатора треда/процесса. (Рекурсивный чуть сложнее, но не суть).


WH>Особенно если вспомнить про различные lock-free структуры данных.


Это к теме не относится, т.к. однофигственно применимо к любым примитивам синхронизации.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[13]: C++0x начали урезать
От: vdimas Россия  
Дата: 11.12.07 10:38
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>Ибо под семафор может зайти только N=const потоков. Для того чтобы вошол новый старй должен выйти. Просто по определению.

WH>А через этот примитив может пройти сколько угодно потоков.
WH>Ну и где тут семафор?

Самому не стыдно? Потрать пять минут и пофантазируй. Намекну — ты всё правильно говоришь, именно, что кто-то должен "выйти", представь семафор объектом с методами enter(int timeout) и exit() и распиши событие на нём. Достаточно сделать допущение, что exit() выполняется из произвольного треда, что есть по факту, т.к. классический семафор — это структура, не запоминающая идентификаторы потоков.


V>>Еще раз, все примитивы синхронизации делаются на семафорах, принципиально,

WH>В теории любой примитив синхронизации можно выразить через любой другой примитив синхронизации.
WH>Но на практике так никто не делает ибо тормозит.
WH>А чтобы не тормозило каждый примитив синхронизации выпиливают под конкретную железку.

Ну конкретно на 86-й железке делается через InterlockedIncrement/Decrement, т.е. через семафоры в совокупности с планировщиком в итоге. На дековской Alpha тоже, кстати.


V>>Это к теме не относится, т.к. однофигственно применимо к любым примитивам синхронизации.

WH>Очень даже относится.
WH>Ибо не смотря на теорию на практике все делать через семофоры это дурь полная ибо тормоза.

Ты там говорил об некоторых структурах, которые могут обходится без синхронизации вообще, так вот оно и было не по теме.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[6]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 12.12.07 11:31
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>А вообще, вы ребяты совсем неадекватны. Не стоит ассоциировать себя с языком на котором вам приходится писать.

VD>На оборот надо адекватно оцинивать обстановку. Вы используете марально устаревший, кривой язык. Используете потому что других не знаете или потому, что работу только на нем дают. Первое проблема вашего образования (и ее стоит исправить), второе проблема рынка (и с ней ничего не поделаеть). При таком подходе издевки над С++ уже не будут задевать вас за живое. Вот берите пример с Вольфхаунда. Он отлично знает С++ и использует его на работе, так как это требование работадателя. Однако оценивает язык совершенно адекватно.


Хммм.... Похоже ты его боишься...
Иначе почему вообще столько внимания и желания унизить такую "кривую" и "бесполезную" штуку?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[9]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.12.07 13:06
Оценка: +1
Здравствуйте, Nuzhny, Вы писали:

N>Разного рода обработка видео в системе видеонаблюдения. В данный момент это детектирование и разпознавание движущихся объектов.


Сдается мне, что для подобных задач клоны ML-я намного лучше подходят.
Изучи хотя бы тот же ОКамл. Если сложно осваивать необычный синтаксис можешь попробовать тот же Немерле, а потом уже когда концепции поймешь, то и на ОКамл пересесть не трудно будет.

В ОКамле как раз параметрический полиморфизм на всшем уровне реализован. И классы есть. А еще есть не менее полезные вещи как лямбды с замыканиями, автоматический вывод типов, сборщик мусора, алгероические типы и паттерн-матчинг. Они твои задачи обработки видео облегчат очень существенно. Ну, а если надо будет на тех же плюсах что-то сбацать, то их интегрировать не очень сложно.

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

Единственная проблема — С++ перестанет казаться самым подходящим языком для большинства применений.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: C++0x начали урезать
От: WolfHound  
Дата: 12.12.07 14:14
Оценка: +1
Здравствуйте, vdimas, Вы писали:

V>В моём упрощённом примере реализации евента на семафоре есть недостаток — в том, что нельзя вызывать Set когда и так уже в signaled state, и Reset если уже сброшен, т.к.

Вот сначала сделай не упрощенную реализацию, а потом посмотрим в какое колличетво syscall'ов уложится каждый метод...

V>я хотел лишь продемонстрировать логику выражения евента через семафор (ведь об этом шёл спор).

Ты вобще читаешь что я пишу?
Я сразу сказал:

В теории любой примитив синхронизации можно выразить через любой другой примитив синхронизации.
Но на практике так никто не делает ибо тормозит.
А чтобы не тормозило каждый примитив синхронизации выпиливают под конкретную железку.

Проблема не в том что все можно реализовать имея один семафор, а в тормозах.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 13.12.07 10:39
Оценка: :)
Здравствуйте, EvilChild, Вы писали:

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


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


C>>Совсем сильно вычислительный код на OCaml'е писать плохо — все же оптимизирует он математику не так здорово, как Intel C++ или даже MSVC. С целой арифметикой там тоже определенные заморочки есть.

EC>И с многопоточностью у него неочень — GC не многопоточный.


А до предложенной модели памяти и сопутствующей библиотеки поддержки вообще всем ныне существующим языкам далеко.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[13]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.12.07 16:01
Оценка: :)
Здравствуйте, ironwit, Вы писали:

I>Влад. ну ты блин Ваааще

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

Лезут тут разные, а потом вещи пропадают (с).

Это вообще-то не для тебя писалось.
Человек у которого в списке интересов Эрланг стоит сам кому хочешь должен все рассказать.

А если кому интересны примеры, то путь лезут куда-нить вроде http://ocaml.spb.ru и смотрят. Вот только боюсь, что для чистого С++-ника это будет все одно что книжки на китайском. По крайней мере я раньши это именно так и понимал.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 13.12.07 17:48
Оценка: +1
Здравствуйте, Константин Л., Вы писали:

КЛ>Введут, и я от этой фичи не в восторге. Разве что для foreach полезна



auto необходим для таких случаев:

template<typename T>
void f(T t1, T t2)
{
  auto R = t1 + t2;
  //...
}


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



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[16]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.12.07 14:14
Оценка: +1
Здравствуйте, palm mute, Вы писали:

PM>Считаем строки:

PM>
PM>$  wc -l *.ml luascanner.mll luaparsex.mly
PM>  3107 total 
PM>


PM>Теперь оцениваем версию на C. Сгенерированный парсер тоже удаляем, заголовочные файлы тоже не рассматриваем (просто, чтобы никто не возмущался , по-хорошему надо бы их оставить, т.к. все определения типов находятся там, дублирования, как в случае Окамла, нет):

PM>
PM>$ wc -l `find . -name *.c -or -name '*.stx'` # *.stx - это исходники парсера
PM>  7083 total
PM>


PM>Получаем разницу в 2 раза, что и требовалось доказать.


По-хорошему, из тех и других исходников нужно выкосить комментарии и пустые строки. В OCaml-е нужно выбросить строки, содержащие только end, а из C -- строки с единственными { и }.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[18]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.07 15:40
Оценка: :)
Здравствуйте, remark, Вы писали:

WH>>И это весьма примитивный пример.

WH>>При попытке повторить это у тебя будет ужасное нагромаждение кода
WH>>
WH>>| Call (OpCode ("=="), [nested_cond,
WH>>    Parm where (expr = TExpr.TypeConversion(TExpr.Literal(Literal.Bool(true)), _, _))], _) =>
WH>>    emit_branch(nested_cond.expr, else_label)
WH>>


R>Так это и тут выглядит как "ужасное нагромаждение кода". То, что это удалось запихнуть в 3 строчки, не является показателем хорошести кода. Вполне возможно, что я предпочёл запись этого кода в 10 строк.


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

R>Писать на С я не призываю. Я лично пишу на С++ и мне нравится.


А что таогда приводишь не типобезопасные примеры на С? Приводи типобезопасные на С++. Благо с некоторым трахом он это позволяет делать.

R> Компилятор контролирует код не меньше, чем в других современных языках,


Ну, меньше конечно. Но даже не в этом суть. Тут речь то ведь была о паттерн-матчинге. О том, чего ни в С ни в С++ даже в проекте нет (смотрим этот самы 0х).

R> а учитывая распространённость С++, возможно, что и больше.


Забавная логика. Это же как же распространенность влияет на типобезопасность?
Ты о чем вообще?

R>Индексы я использую редко. Что будет, если ошибусь? Исключение или ассёрт скорее всего.


Скорее AV.

R> Вообще индексы я использую редко. Они сами по себе провоцируют ошибки. Обнаружение большинства ошибок я стараюсь переносить на фазы компиляции/линковки/стартапа. Имхо смысл иметь исключение, где по сути должен быть ассёрт не много.


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

R>Если забуду "else throw" — компилятор предупреждает от неполных switch, отсутствии return, неопределённых виртуальных функциях.


Какой такой не полный switch? 1. Это ведь не Шарп где default обязателен. 2. Ты if использовал. Иначе откуда else? Вот в Немерле if без else попросту невозможен. А в твоих любимых плюсах у тебя будет банальная логическая ошибка которая приведет к банальному подению в рантайме. Причем с огромной вероятностью попрортишь память (что вообще невозмоно в безопасных языках).

R>Код на немерле не падает "у клиента"? Даже если неправильно указать индекс?


AV точно не будет. Рантайм все проконтролирует. Да и Немерле тот язык где как раз можно отлично жить без индексов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: C++0x начали урезать
От: WolfHound  
Дата: 14.12.07 15:42
Оценка: :)
Здравствуйте, remark, Вы писали:

R>union решает эту проблему — под каждый тип функции своё кол-во аргументов с нужными типами

За то создает огромное колличество других.
union не типобезопасный!

R>Во-первых, это не ровное место. Скорее всего тут содержится какая-то логика. Какая именно, к сожалению, не представляется возможным понять.

Нет там никакой логики.
Просто сравнение с образцом.

R>С С напротив, логика максимально прозрачная — есть только тривиальные конструкции.

В С логики максимально спрятана за кучуй присяданий.

R>Именно поэтому С является "интернациональным" языком общения между разработчиками.

R>Львиная доля всех алгоритмов и научных статей использует именно С (иногда С++, pascal, java), но никогда функциональные языки (если это только не статья по функциональным языкам), т.к. автор не хочет на ровном месте терять большую часть читателей.
Я думаю тут все проще: автор банально ничего другого не знает.

R>Поэтому же С используют крупнейшие опен-сорц проекты — linux, postgresql и т.д.

Они его используют исключительно по историческим причинам. Ну написали когдато пара ребятишек мега ОСь UNIX и для того чтобы ее было проще портировать написали переносимый ассемблер ака С. И все начали это безобразие куда попало переносить...
Правда потом ребята поняли свои ошибки и сделали и болие другую ОСь и создали для этого болие другой язык но миллионы мух досихпор продолжают тащить то самое безобразие которое получилось у этих ребят в начале.

R>Зато влияет на детектирование ошибок компилятором — о чём я и говорил.

Бред.

R>Я привык больше верить своим глазам:

R>

R>warning: enumeration value `x3' not handled in switch

Код покажи.

R>

Черезмерное употребление алкоголя вредит вашему здоровью.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: C++0x начали урезать
От: FR  
Дата: 14.12.07 16:27
Оценка: +1
Здравствуйте, VladD2, Вы писали:

FR>> там есть вполне сопоставимые по сложности с ядром компилятора вещи. Да и занимается во многом тем же самым эмуляцией высокоуровневых фич


VD>Можно смело утверждать, что он проще просто потому, что не все фичи он эмулирует.


Вообще конечно сравнение теплого с зеленым
Если сравнивать только компилятороэмуллирующие части буста, то да проще, если в целом то (теплое с зеленым) скорее наоборот.
Re[19]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 17:04
Оценка: :)
Здравствуйте, VladD2, Вы писали:

R>>Писать на С я не призываю. Я лично пишу на С++ и мне нравится.


VD>А что таогда приводишь не типобезопасные примеры на С? Приводи типобезопасные на С++. Благо с некоторым трахом он это позволяет делать.



Вот, пожалуйста. Меньше, кстати, получается:

struct BinIntCall {string name; int a1, a2;};
struct BinOp {string name; any a1, a2;};

void to_str(any e)
{
    if (double* d = any_cast(e)) cout << *d;
    else if (BinIntCall* c = any_cast(e)) cout << c->name << "(" << c->a1 << "," << c->a2 << ")";
    else if (BinOp* c = any_cast(e)) to_str(c->a1); cout << c->name; to_str(c->a2);
    else throw 0;
}





1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[27]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 19:33
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

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


R>>Да в принципе и так варнинг есть:

R>>
R>>double eval(const expr* e)
R>>{
R>>    if (0 == strcmp("min", e->data.name) && 2 == e->data.count)
R>>        return min(eval(e->data.params[0]), eval(e->data.params[1]));
R>>    else if (0 == strcmp("max", e->data.name) && 2 == e->data.count)
R>>        return max(eval(e->data.params[0]), eval(e->data.params[1]));
R>>}
R>>

WH>Э нет... давай по взрослому.
WH>Давай с несколькими опкодами, и чтобы Call был в свитче не первым.


double eval(const expr* e)
{
    switch (e->t)
    {
    case expr::Plus:
        return 0;
    case expr::Call:
        if (0 == strcmp("min", e->data.name) && 2 == e->data.count)
            return min(eval(e->data.params[0]), eval(e->data.params[1]));
        else if (0 == strcmp("max", e->data.name) && 2 == e->data.count)
            return max(eval(e->data.params[0]), eval(e->data.params[1]));
    }
}



'eval' : not all control paths return a value




1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[20]: C++0x начали урезать
От: jazzer Россия Skype: enerjazzer
Дата: 19.12.07 11:33
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


VD>>>Да, и не решают они ничего. Они позволяют прояснить интерфейс параметра типа. Но не зсаставляют использовать их везде. Что создает недетерминизм.

EC>>Мы говорим об одном и том же: консептам из драфта нового стандарта C++?

VD>Ага. Они не обязательны для применения. Как я пониял ты по рпежнему сможешь писать код без концептов.


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

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

Так что не очень понятно, о чем была твоя реплика.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[23]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.12.07 15:34
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>Зачем кому-нибудь C++ без препроцессора и указателей?


Я бы упростил бы это вопрос. Например, так:

Зачем кому-нибудь C++?

или даже:

Зачем C++?




А если серьезнь, то есть менее кривые средства. Те же текстуаьные макросы можно заменить немерлоподобными. Указатели пусть остаются, но только в опасном контексте (как в Шарпе). Так чтобы можно было четко выделить опастные куски кода и проверять их более дотошно. А то в любом месте многомегобайтного кода программы может появиться адресная арифметика в следствии которой будет испорчена память и бедный В.Пупкин будет вынужден месяцами тупо смотреть на корректный код не понимая почему он не работает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.12.07 16:05
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


E>>Зачем кому-нибудь C++ без препроцессора и указателей?


VD>Я бы упростил бы это вопрос. Например, так:

VD>

Зачем кому-нибудь C++?

VD>или даже:
VD>

Зачем C++?


VD>


За него платят.

VD>А если серьезнь, то есть менее кривые средства. Те же текстуаьные макросы можно заменить немерлоподобными.


Макросы в топку.
Мне препроцессор в C++ нужен для устранения различий между платформами и поддержкой разных режимов компиляции. Ну еще за макросами удобно прятать вещи типа assert или trace, которые из release версии вырезаются напрочь.

Использование C-ных макросов для более серьезных вещей, по моему опыту, является следствием непродуманного дизайна. Когда на поиск более подходящей реализации не хватило времени, подходящих инструментов или хорошей идеи.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[25]: C++0x начали урезать
От: Sergey Россия  
Дата: 19.12.07 16:23
Оценка: +1
> Макросы в топку.

Ни в коем случае.

> Мне препроцессор в C++ нужен для устранения различий между платформами и поддержкой разных режимов компиляции. Ну еще за макросами удобно прятать вещи типа assert или trace, которые из release версии вырезаются напрочь.

>
> Использование C-ных макросов для более серьезных вещей, по моему опыту, является следствием непродуманного дизайна. Когда на поиск более подходящей реализации не хватило времени, подходящих инструментов или хорошей идеи.

Вот именно — не хватает более подходящих инструментов. Поэтому приходится либо навешивать внешний кодогенератор, либо использовать макросы в стиле boost preprocessor. И то и другое — не очень удобно.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[28]: C++0x начали урезать
От: FR  
Дата: 19.12.07 16:36
Оценка: +1
Здравствуйте, Andrei F., Вы писали:

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


E>>>>Вот через 20 лет кто-нибудь поставит Nemerle в упрек то, что он создавался под .NET.


AF>Хрустального шара, чтобы в нем показать, у меня нет. Но сам факт таких высказываний (см выше) уже о многом говорит


А ни о чем не говорит, вон ML появился в 1973 году, в 97 был принят новый стандарт, и сейчас вполне жив и здоров, вот только доля на рынке (даже с диалектами типа Ocaml'а) близка к нулю. Это вполне вероятное будущее и для Немерле.
Re[29]: C++0x начали урезать
От: jazzer Россия Skype: enerjazzer
Дата: 19.12.07 17:48
Оценка: +1
Здравствуйте, eao197, Вы писали:

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


E>>>Внешний DSL и pre-compile-time генерация кода. Чтобы можно было получить результат этой генерации в виде чистого C++ кода. Чтобы затем отладчиком по нему пройтись можно было. А если этот DSL генерирует какие-то классы/функции, чтобы инструменты типа doxygen могли их в отчет включить.


E>>>А то потом всякие эксперименты с созданием своего подъязычка на макросах боком вылазят. По разном причинам. Например, сложно обеспечивать совместимость при необходимости расширения подъязыка.


J>>Оно боком вылазит, если делаешь страшные вещи. А если нужно просто немножко пошаманить — то вполне нормально все работает.

J>>Внешние тулы — они, во-первых, внешние, во-вторых, они работают на уровне всего файла, что обычно совсем не надо.

J>>Ну и неудобно просто, у меня порядком опыта было с такой генерацией, и никогда это удобно не было.


E>А ты можешь привести примеры того, о чем говоришь?


E>А то может получится, что мы вообще о разных вещах разговариваем.

ну представь что у тебя есть код на три строчки и его надо размножить десятикратно прям тут же (case-ы в свитче, скажем), причем к функциям это легко не сводится? даже к шаблонным, потому что различия в типах, в строках (литералах) и т.п.
Вот такие три строчки упрятать под одну строчку макроса и потом эти 10 строчек написать — милое дело, все ясно и понятно.
И надежно, кстати, потому что ты полностью защищен от ошибок копи-пейста — у тебя вместо разноженного трехстрочного блока кода (где черт ногу сломит и не поймешь, правильно ли все употреблено или при копи-пейсте всё поменяли, а вот тут забыли) всего одна строчка вызова макроса и каждая сущность там упоминается ровно один раз.
И сразу после этих 10 строчек поставить #undef
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[25]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.07 15:57
Оценка: +1
Здравствуйте, jazzer, Вы писали:

VD>>или даже:

VD>>

Зачем C++?


J>или даже:

J>

Зачем?


Это уже теряет смысл. Тогда лучше так:
С++?

VD>>Те же текстуаьные макросы можно заменить немерлоподобными.

J>Вот тут я согласен. Немерлевые макросы в С++ я очень хотел бы видеть — то, что сейчас делается текстовым препроцессором, стало бы гораздо читабельнее, проще и надежнее. Ну и еще кое-что хотел бы видеть, но это нереально, по крайней мере, в текущей редакции языка (слишком глубоко придется лезть в его объектную модель).

О том и речь. Потому я уже лет 5 как забил на то чтобы что-то ждать от С++.

J>Насчет остального — ну вот я уже столько времени не напарывался на проблемы с адресной арифметикой...


Ладно я эту тему даже развивать не хочу. Все круты до тех пор пока жареный петух в зад не клюнет, а потом нчинается "Какой козел тут напортачил?...". Потом ты не один. Ну, и даже гении тратят времы и силы на соврешенно бессмысленный контроль. Вн тот же Паша на што уж знаток и фанат С++, но когда попробовал на Питоне пописать, так сразу стал говорить о том насколько это проще.

J> Но это, конечно, при условии, что у тебя в проекте не работают студенты.


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

J>Но при этом другого способа пройтись по встроенному массиву или встроенной строке, кроме адресной арифметики, нету, если не хочется терять скорость, конечно.


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

J>Хотя в моем коде подобные вещи обычно упрятаны в классы либо просто используются алгоритмы STL.


Тебе не кажется маразмом тот яакт, что ты не можешь напрямую пользоваться такими базовыми фичами как массиы? И не кажется, что раз уж даже массивы не являются небезопасными, то крайне важно встроить в язык понятие безопасного и небезопасного контекста, так чтобы глядя на прикладной код ты четко понимал, что в нем не может оказаться адресной арифметики и т.п.? Вот в коде STL пусть убдет четко выделенный участок кода реализующий базовые вещи. Но не в прикладном же коде?!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: C++0x начали урезать
От: WolfHound  
Дата: 20.12.07 15:59
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>Вот сильно сомневаюсь, что такие вещи, как константность, замыкания, lazy-аргументы, scope-классы и scope.exit, design by contract могли бы уехать в стандартную библиотеку.

Так в немерле половина того что ты перечислил туда и уехала.
Причем изначально это делали посторонние люди.

E>Ну или метапрограммирование на шаблонах, которое использует побочный эффект.

Это делается исключительно из-за того что нет нормальных макросов.

E>И, в моем понимании, нормальный язык и должен так развиваться. Все нововедения только через основную команду разработчиков.

Основная команда разработчиков не резиновая.

E>Так вот мне и кажется, что если разработчик не смог придумать такие высокоуровневые классы и методы, которые бы позволили лаконично решить задачу, то где гарантия, что он сможет сделать это с помощью языка?

В техже компиляторах есть куча кода которая генерится по шаблонам.
Никаким ООП это не объехать.

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


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

Не вижу связи.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: C++0x начали урезать
От: minorlogic Украина  
Дата: 03.01.08 11:46
Оценка: -1
Здравствуйте, EvilChild, Вы писали:

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


EC>Concepts эту задачу решают. Некий аналог классов типов Хаскеля.


К сожалению в плюсах шаблоны изначально криво встроенны , и Concepts эти слабая попытка лечения. А вылечить концептальные проблемы скорее всего не получится.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[23]: C++0x начали урезать
От: deniok Россия  
Дата: 09.01.08 20:15
Оценка: :)
Здравствуйте, EvilChild, Вы писали:

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


EC>>>Так консепты как раз эту задачу и решают или я что-то упустил?


M>>Нет. Они частично пытаються ее решить. К сожалению или счастью , использование концептов необязательно.


EC>Почему частично? Чего не хватает для полного счастья кроме необязательности?


Лично мне — изоморфизма Карри-Ховарда
Re[24]: C++0x начали урезать
От: Programador  
Дата: 09.01.08 23:50
Оценка: :)
Здравствуйте, deniok, Вы писали:

EC>>Почему частично? Чего не хватает для полного счастья кроме необязательности?


D>Лично мне — изоморфизма Карри-Ховарда



и как долго тогда Комитет будет обсуждать аксиому выбора?
Re[19]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.01.08 12:43
Оценка: :)
Здравствуйте, Константин Л., Вы писали:

КЛ>Зачем лечить мифические болезни? Ты не думал, что эта кривость для создателей было то, что нужно? Чем плох пистолет по сравнению с автоматом? Видимо тем, что он решает те же задачи, но в других ситуациях.


Обожаю аналогии! Здесь уместнее будет не пистолет, а вилка. Ей тоже можно убить. Причем так как у нее 4 острых части, то теоритически она в 4 раза эффективнее любого пулемета .

КЛ>Меня иногда коробит "концептность" .net generics.


Хороший пример. Давай я тебе поясню на нем чем плохи шаблоны С++. Дженерики проектировались специалистами с серьезной мат.подготовкой. Они были продуманы, птестированы, подверглись крититике со стороны коммерческих программистов и в итоге были после доводки реализованы теми самыми коммерческими программистами. При этом учидывались следующие факторы:
1. Дженерики должны были обеспечивать параметрический полиморфизм (это же делают шаблоны).
2. Дженерики должны быть безопасны и просты в применении (этого у шаблонов нет... возможно концепту чуть поправят ситуцию, но устранить излишнюю сложность уже никогда не удастся).
3. Дженерики должны быть применимы только для обобщенного программирования (шаблоны же в виду излишней мощьности на сегодня часто применяются для метапрограммирования во время компиляции).
4. Дженерики не должны нарушать других систем динамической ОО-системы типов. Они обязаны поддерживать модульность и распространение в бинарных сборок (шаблоны С++ суность времени компиляции и их фактичесуки невозможно сделать модульными).
5. Дженерики должны поддерживаться Intellisense-ом в IDE (это тоже, в виду переусложныенности в полной мере шаблонам не доступно, причем в частности из-за пунткта 4).

В итоге мы имеем:
1. Шаблоны несомнее мощьнее дженериков, так как кроме параметрического полиморфизма они так же обеспечивают возможности метапрограммирования.
2. Шаблоны несомнее мощьнее дженериков, так как они производят прямые подстановки кода во время компиляции, что позволяет добитьсе большей эффективности кода.
3. Шаблоны несонменно переусложнены и разработка чего-то сложнее чем одноуровневые шаблоны доступна ограниченному (и довольно узкому) кругу лиц.
4. Шаблоны несомненно несовместимы с модульностью и динамикой.
5. Шаблоны слишком часто используются для решения задач на которые они не рассчитаны (метапрограммирование), и в то же время в языке почти нет других средств метапрограммирования (за исключением и препроцессора использование которого является так же багодромом).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: C++0x начали урезать
От: Andrei F.  
Дата: 11.01.08 08:53
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


Только ни одному из этих горе-специалистов не хватило сообразиловки сделать констрейнты на new с параметрами, или например простейший оператор сложения. Вот и появляются потом извраты с активатором или рефлекшеном Не говоря уже о такой маленькой но жутко полезной фиче как type alias.
В общем, косяков у генериков тоже более чем достаточно.
Re[29]: C++0x начали урезать
От: Andrei F.  
Дата: 01.02.08 05:59
Оценка: :)
Здравствуйте, FR, Вы писали:

FR>А ни о чем не говорит, вон ML появился в 1973 году, в 97 был принят новый стандарт, и сейчас вполне жив и здоров, вот только доля на рынке (даже с диалектами типа Ocaml'а) близка к нулю. Это вполне вероятное будущее и для Немерле.


Это вероятное будущее для динозавров вроде D и ему подобных. И даже не вероятное, а практически гарантированное.
А настоящее будущее — за Немерле или другими языками, которые будут устроены по тому же принципу. Если, к примеру, макросы встроят в C#, то это тоже будет вполне неплохо.
Re[41]: C++0x начали урезать
От: Klapaucius  
Дата: 04.02.08 13:50
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>В Sign# есть, в D есть, в Nice есть такие же контракты. И команды там были не на много больше, чем у Nemerle.


Над статической проверкой контрактов в Spec# работала команда специалистов, превышающая, насколько мне известно, количество основных разработчиков D, Nice и Nemerle вместе взятых. При этом, их статический верификатор можно подключить к Nemerle просто как библиотеку. И работа эта была проделана сторонним контрибьютером без изменений компилятора Nemerle.
Можно ли подключить этот статический верификатор контрактов к D или Nice? Вопрос риторический, конечно.
... << RSDN@Home 1.2.0 alpha rev. 774>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[38]: C++0x начали урезать
От: FR  
Дата: 04.02.08 16:37
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Тут есть два соображения:

VD>1. Объем знаний требуемый для использования ФП сильно приувеличен. Просто учить ему не умеют. Раньше ФП учили близкие к математике и вообще науке люди. Резльтат получался плачевным. Из простешей вещи они сразу же учудили мозголомство.

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

VD>2. В том то и дело, что если знать Шарп (а таких программистов очень много), то фунциональные вещи осваиваются довольно легко и, что не маловажно, прямо во время работы над каким-нибудь проектом. Желательно только чтобы при этом рядом с новичком работал кто-то кто уже прошел этот пукть и может потихоничку направлять новичка в нужное русло.


Угу только по моему в резулmтате получаются больше "пользователи сахара"
Re[38]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.02.08 10:28
Оценка: :)
Здравствуйте, Трурль, Вы писали:

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


E>>Я таки услышу ответ на вопрос о том, к пределу какой сложности приближается разработка современных языков программирования?

Т>

Я по секрету сознаюсь, что этот компилятор с Модулы уже на пределе допустимой сложности, и я бы чувствовал себя совершенно неспособным создать хороший компилятор для Ады.
Т>Н. Вирт


Ну вот, хоть что-то.
Тем не менее, со времен создания компиляторов Модулы и Ады что-то же изменилось, раз существуют такие вещи, как С++ и C# 3.0.

И еще вопрос, смогли бы на ядре Nemerle создать компилятор Ады.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[56]: C++0x начали урезать
От: FR  
Дата: 06.02.08 11:23
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

FR>>Я думаю просто нужно чтобы Aлександреску заинтересовался Немерле

WH>Он ничего не придумает.
WH>Да и что можно придумать если уже есть полные по Тьюрингу макросы?

Даже я могу кучу вещей придумать в которых полные по тьюрингу макросы мало чем помогут, например добавь подержку продолжений ( http://en.wikipedia.org/wiki/Continuation ), или мультиметов в стиле CLOS, или нормальную ленивость, думаю в этот список можно еще немало вещей добавить и со временем список будет только расти.
Re[51]: C++0x начали урезать
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 06.02.08 11:34
Оценка: +1
Здравствуйте, EvilChild, Вы писали:

WH>>Коротко нельзя да и НДА.

EC>Тогда как аргумент в пользу макросов это звучит малоубедительно.

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

Иногда подобные ситуации связаны с ограничениями в языке. Поскольку я работаю на Яве, то могу много про это рассказать В C# с этим получше, но не замечательно. Вообще, ИМХО, чем больше в языке конструкций являются first-class citizen, тем лучше — нет ограничений на их применение. Если же ограничения есть, то приходится для двух схожих задач, отличных только по этим ограничениям применять два схожих куска кода вместо одного. Эту дыру можно прикрыть кодогенерацией или макросами (на них можно смотреть, как на один из способов кодогенерации).

Примерно так.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[65]: C++0x начали урезать
От: WolfHound  
Дата: 06.02.08 15:29
Оценка: :)
Здравствуйте, VoidEx, Вы писали:

VE>Я, конечно, могу ошибаться, но Ваши ответы очень смахивают на ответы:

Если уж проводить аналогии то все выглядит так:
1)Шаблоны это крууууутоооо!!!!
2)Чем круто? Да и вот тут проблемы вылезают.
3)Да ты ваще выще ничего не понимаешь!
4)Как всегда одни эмоции.
5)Да ты все игнорируешь!!!
6)Так ты покажи что тебе не нравится? Да и что с той проблемой то делать?
...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[68]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 06.02.08 20:14
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

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

WH>А вот с этого места давай подробнее... ибо у нас есть изменяемые переменные... как ты их откатывать будешь?
WH>А еще есть IO...

Здесь явно какая-то путаница — в схеме же есть продолжения, хотя она и близко не чистый язык.
now playing: Autechre — SonDEremawe
Re[53]: C++0x начали урезать
От: WolfHound  
Дата: 06.02.08 21:10
Оценка: :)
Здравствуйте, EvilChild, Вы писали:

EC>Я примерно представляю для чего они нужны, но было сказано, что возникла реальная необходимость, и как только захотелось узнать подробности — так сразу НДА и прочие отмазки.

Так эта... см код компилятора там их полно... например SupportRelocation

EC>Вот если бы LINQ приделали на макросах это был бы убийственный аргумент.

Если бы оно было сильно надо...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[60]: C++0x начали урезать
От: jazzer Россия Skype: enerjazzer
Дата: 07.02.08 03:50
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

FR>>То есть все что не можем сделать на макросах зло, понятно.

WH>
WH>
WH>class A {}
WH>class B : A {}
WH>...
WH>void fn(A, B)...
WH>void fn(B, A)...
WH>...
WH>fn(new B(), new B());
WH>

WH>Какую функцию вызывать будем?

Никакую, ошибка "неоднозначность вызова" (в зависимости от модели — ошибка компиляции, линковки или даже исключение типа NullObjectException) . Если так надо вызвать функцию для двух В, то придется реализовать fn(B, В).

То же самое мы имеем и сейчас с обычной перегрузкой, единственная разница — нужно учитывать, что перекрытая функция в случае мультиметодов может прийти из другой библиотеки/сборки/файла.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[71]: C++0x начали урезать
От: WolfHound  
Дата: 07.02.08 13:50
Оценка: :)
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Это не верно просто потому, что эти макросы не работают в run-time.

Данное утверждение не верно.
Компилятор и как следствие макросы можно использовать в run-time...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[58]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.02.08 14:56
Оценка: +1
Здравствуйте, Andrei F., Вы писали:

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


E>>Тем не менее, этих явно поверхносных знаний оказывается достаточно, чтобы утверждать, что между D и C++ возможна прозрачная интероперабильность, да еще с учетом шаблонов, множественного наследования, различных объектных моделей, разных систем поддержки исключений и сборки мусора?


AF>И снова бинарное мышление. Или всё, или ничего.

AF>Кстати, это оказывается довольно распространенное явление, которое называется "патологический перфекционизм".

хм... Как я вас понял, интероп с C++ нужен для того, чтобы в D использовать существующие наработки из C++. Итак, мне по работе приходится использовать такие библиотеки, как Crypto++ и ACE. Интересно было бы услышать, как мог бы выглядеть в D интероп с этими библиотеками.

В особенности интересно использование каркасов ACE_Reactor и ACE_Acceptor/ACE_Connector. Вкратце: для того, чтобы использовать ACE_Acceptor, необходимо сделать класс, производный от ACE_Svc_Handler -- он будет обрабатывать входящие соединения. При этом класс ACE_Svc_Handler шаблонный и должен параметризоваться типом транспорта. Так же нужно создать наследника ACE_Acceptor для того, чтобы переопределить методы создания и настройки конкретных Svc_Handler-ов, при этом ACE_Acceptor так же параметризуется. Аналогичные классы нужно создавать и при работе с ACE_Connector.

Итак, я хочу использовать ACE, но создавать наследников ACE_Svc_Handler и ACE_Acceptor/ACE_Connector в D, а потом передавать указатели на обратно в ACE (в ACE_Reactor, в частности).

Каким образом это будет выглядеть без патологического перфекционизма?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[59]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:13
Оценка: -1
Здравствуйте, lomeo, Вы писали:

L>На самом деле тут о чём разговор? О том, что если макросы есть, то всё — можно уже не расширять язык или что?


Нет конечно. Это у FR аргументы кончились вот он и подменил обсуждаемый вопрос. А тема, вообще-то про С++ была. Вот только что-то тут его совсем не обсуждают .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[62]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 07.02.08 19:18
Оценка: +1
Здравствуйте, VladD2, Вы писали:

FR>>Я пока только изучаю продолжения, но кажется файберы тоже только частный случай, они без проблем на call/cc реализуются.


VD>Файберы работают вне языков. Так что это очередная ерунда. Ты можешь написаать call/cc который я смогу использовать из Шарпа? Файберы это те же потоки, только без раздачи квантов времени и с ручным переключением.


Файберы это вообще абстракция из другой оперы, ты их по ходу с coroutines путаешь.
now playing: Autechre — Perlence
Re[68]: C++0x начали урезать
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 07.02.08 21:25
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Все варианты полиморфны априори.


Полиморфные варианты — это не АТД Это такие конструкторы, отвязанные от типа. Они есть, например, в OCaml.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[59]: C++0x начали урезать
От: Andrei F.  
Дата: 08.02.08 03:45
Оценка: :)
Здравствуйте, eao197, Вы писали:

E>Итак, я хочу использовать ACE, но создавать наследников ACE_Svc_Handler и ACE_Acceptor/ACE_Connector в D, а потом передавать указатели на обратно в ACE (в ACE_Reactor, в частности).


В данном случае, видимо, надо поумерить желания и поискать более простой способ интеропа.
Re[60]: C++0x начали урезать
От: FR  
Дата: 08.02.08 03:57
Оценка: +1
Здравствуйте, Andrei F., Вы писали:

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


В таком случае очень большую часть C++ библиотек будет невозможно использовать.
Более простой и ограниченный интероп уже есть.
Re[63]: C++0x начали урезать
От: Andrei F.  
Дата: 08.02.08 04:56
Оценка: +1
Здравствуйте, FR, Вы писали:

FR>Пойми реально D сильно отличается от C++. Практически не меньше чем шарп. И продолжить на нем проект не получится.


Я понимаю. C# от C++ еще больше отличается, но организовать между ними интероп у МС получилось очень даже неплохо. И поддерживать проекты, где они существуют бок о бок — это совсем не проблема.
Re[65]: C++0x начали урезать
От: Andrei F.  
Дата: 08.02.08 10:23
Оценка: :)
Здравствуйте, eao197, Вы писали:

E>Может тогда расскажите, как решить вышеупомянутую задачку с ACE в .NET?


Вероятно, придется делать неуправляемый класс-наследник и обертки для управляемых функций.
Re[50]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.02.08 13:52
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

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


E>>Может покажешь, как макросы require и ensure использовать как вызов функции?

WH>Их можно использовать с синтаксисом атрибутов.
WH>Ты бы хоть камент к Ensures посмотрел.
WH>
WH>     Example:  [Ensures (foo () != 4)]
WH>            foo (i : int) : int { ... }
WH>


Тогда два вопроса:

* если все это можно сделать без макросов, на анотациях, то зачем макросы?
* что делать с макросами, которые в анотации не засунуть? Насколько я понимаю, вещи типа using и for в Nemerle -- это макросы. Они так же функциями заменяются?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[51]: C++0x начали урезать
От: WolfHound  
Дата: 08.02.08 14:03
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>* если все это можно сделать без макросов, на анотациях, то зачем макросы?

Еще раз:
Это не атрибуты. Это макросы с синтаксисом атрибутов.

E>* что делать с макросами, которые в анотации не засунуть? Насколько я понимаю, вещи типа using и for в Nemerle -- это макросы. Они так же функциями заменяются?

Еще раз:
Это не функции. Это макросы с синтаксисом функций.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[57]: C++0x начали урезать
От: WolfHound  
Дата: 08.02.08 14:03
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>Продукты на Nemerle уже достигли такого уровня продаж?

Через 20 лет посмотрим.

E>Способен ли на это Nemerle?

Не хуже чем питон, руби и прочие поделки.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[54]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.02.08 16:21
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

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


E>>, злоупотребление локальными функциями.

WH>И что бы по твоему изменилось если бы я их не использовал?

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

WH>А я тебе скажу: Пришлось бы завести еще пару классов. И раздуть код раза в 2. Минимум.


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

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

WH>А в чем проблема?
WH>Ибо библиотеками особенно под С/С++ дров можно наломать как минимум не меньше.

Ну не про C/C++ сейчас речь, я так думаю.

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

E>>Согласен, здесь я привел неудачный пример.

E>>В D, думаю, аналог Memoize, можно сделать как шаблонную обертку над методом. И вызвать потом не сам метод, а его обертку. Так же можно поступать и в Nice, хотя здесь могут быть сложности с переменным числом аргументов.
WH>В том то и прелесть макросов что я написал и отладил этот код (Problem178)
Автор: WolfHound
Дата: 04.02.08
для маленьких значений, а потом просто дописал Memoize и получил дикое ускорение.


Думаю, что если бы Memoize был реализован на D-шных шаблонах, эффект получился практически таким же. Было бы что-то вроде:
ulong step(int cur, int len, int bits)
{
  static ulong delegate(int, int, bits) calculator;
  ulong step_impl( int c, int l, int b )
  {
    auto b2 = b /*тут не понял*/ (1<<c);
    auto l2 = l - 1;
    if( 0 == l2 )
      return ( b2 == 0x3ff ? 1l : 0l );
    else
    {
      ulong rec( int c2 )
      {
        if( c2 < 0 || c2 > 9 ) return 0L;
        else return calculator( c2, l2, b2 );
      }
      return rec(c + 1) + rec(c - 1);
    }
  }
  if( calculator is null ) calculator = &step_impl;
  return calculator( cur, len, bits );
}

После того, как на маленьких числах это дело отлажено, можно переделать одну строку:
if( calculator is null ) calculator = memoize(&step_impl);


Кстати, по ходу вопрос -- Memoize на локальные функции распространяется?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[61]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 17:11
Оценка: -1
Здравствуйте, lomeo, Вы писали:

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


VD>>Я правильно понял, что по реализуемости мультиметодов и т.п. вопрос отпал?


L>На самом деле спор совершенно дурацкий. Началось с заявления, что на макросах можно сделать всё (я утрирую, но это можно было так понять).


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

Я помню, что Вольфхаудн высказал резнонное, на мой взгляд, мнение о том, что языки резонно создавать на безе сикроядра, а остальные фичи наворачивать на чем-то вроде мощьной макросистемы. И сказал, что мол по его ИМХУ за таким подходом будущее. Ну, и пошло поехало. Основную мысль никто не осприл. Зато спор перешел в разряд абсурдного.

L> Когда были предъявлены варианты того, что сделать нельзя, то, разумеется, в ответ получили недоумение на фига это делать.


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

Наши заслуженные демогоги FR & eao197 в очередной раз сделали логический подлог, а вы поддержали их почин.

По крайней мере мне так показалось.

L>1. Либо доказать WolfHound-у (и компании), что на макросах сделать всё нельзя, но я думаю, он это и так понимает.

L>2. Либо доказать FR (и компании), что мультиметоды Немерле не нужны. Но его это тоже мало интересует.

Ну, и погляди на результат разговора.
Вольфхаунд:
— Я считаю, что за подходом микроядро плюс равитие на макросах будущее.
FR:
— А мультиметоды можно сдлать?
— Можно, но не нужно.
— А почему не нужно? Значит нельзя, а это доказывает, что подход плохой.
...

L>Остальное — детали. Коротко — о разном говорят, IMHO.


По-моему, они вообще не говорят, а защищают позиции. FR отстаивает све болото. Он не приемлет тот же Немерле по причинам к дизайнерским решениям принятым в языке не относящимся, а Вольфхаунд начав спорить с ним ушел в нервану, забыл о предмете разговора и начал говорить не самые разумные вещи.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[59]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 17:11
Оценка: +1
Здравствуйте, lomeo, Вы писали:

L>С последней мыслью немного не согласен. Хардкодить в компиляторе, наверное, да, не стоит. На все случаи не напасёшься. Однако, если есть фича, смотрящаяся достаточно стройно в языке, то это лучше, чем макрос в языке, где этой фичи нет.


Дык не вопрос. Понятие "в языке" довольно гибкое. Это может быть стандартная макробиблиотека. 90% Немерла и лежит в макросах. Более того некоторые фундаментальные фичи, например, поддщержка делегатов, хотя и лежит в коде компилятора, но создано на базе макросного АПИ. Так что я с тобой и не спорю. Я говорю о дизайне компилятора, а не настаиваю на том, что все надо под одну гребенку. В тех же ОС частенько переносят в ядро то что не следовало бы только из соображений скорости. С компиляторами та же фигня.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[59]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 17:11
Оценка: -1
Здравствуйте, VoidEx, Вы писали:

VE>Не смеши, текущими макросами LINQ не сделаешь, хоть убейся, я в курсе почему. Либо другой синтаксис, либо <# #> (что тоже другой синтаксис) или еще какие костыли. Надо систему макросов менять.


Надо будет, поменяем. А ты можещь продолжать жевать, что жевать и заниматься демагогий.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[47]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 17:11
Оценка: :)
Здравствуйте, eao197, Вы писали:

WH>>Все что нужно это запомнить аргументы функции до вызова body и передать их в check.

WH>>Думаю с этим даже ты справишься.

E>Если уж разработчики Nemerle с их гениальными идеями не смогли это сделать, то я даже и пытаться не буду.


Слушай. Ты форумом ошибся. Тут не демогогический клуб, а технический. Кончай упражняться.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[65]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 17:48
Оценка: :)
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Тебе кучу раз приводили continuation-сервера. Ну, не делается оно полноценно на фиберах.


Что не делается. Только без позго...ства. Кокретный простой пример. И плиз чтобы он не был ради себя самого.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[58]: C++0x начали урезать
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.02.08 12:46
Оценка: -1
Здравствуйте, VladD2, Вы писали:

L>>Если говорить откровенно, то я этого момента не помню. Напомни, плз, что за конкретные места и что за анализ, для которых нужна генерация кода? Или ссылку дай на сообщение.


VD>Код доступен http://nemerle.org/svn/nemerle/trunk/macros/compiler.n изучай.


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

L>>А так — да, если обязательно нужна кодогенерация (т.е. язык не может предложить лучшее решение), то макросы рулят. С этим никто не спорит.


VD>Ну, может в некотором проценте случае тот или иной язык предложить не то что бы лучшее, но хоть какое-то решение. И что это основание пользователям других языков говорить о ненужности макросов?


Нет, конечно. Но есть мнение, что в этих языках наличие макроса сигнализирует о том, что в языке нет решения без макросов. Естественного и элегантного, разумеется, иначе его бы не применяли и так.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[68]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.08 06:25
Оценка: +1
Здравствуйте, Andrei F., Вы писали:

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


AF>>>Вероятно, придется делать неуправляемый класс-наследник и обертки для управляемых функций.


E>>И после этого вы еще предъявляете какие-то претензии к D?


AF>Честное слово — удивляюсь, как человек с такими проблемами с логикой вообще может работать программистом.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[68]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.08 07:20
Оценка: +1
Здравствуйте, Andrei F., Вы писали:

AF>Это один-единственный сценарий интеропа, в котором C++/CLI предлагает примерно такое же плохое решение, как и D. Что может доказать одно исключение? Ничего.


Для вас это исключение, для меня такие сценарии -- это повседневная реальность.

AF>Если ты хочешь реально что-то доказать — приведи список наиболее типичных задач, которые решаются интеропом


С удовольствием посмотрел бы на ваш вариант этого списка.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[70]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.08 08:11
Оценка: +1
Здравствуйте, Andrei F., Вы писали:

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


E>>С удовольствием посмотрел бы на ваш вариант этого списка.


AF>Для меня основная задача интеропа — возможность вызывать legacy-код из моего кода. В C++/CLI эта задача решена хорошо. Таким образом, по этому пункту — серьезное преимущество у C++/CLI, а по обратной задаче (вызов нового кода из legacy-кода) мы имеем паритет.


Выделенное является слишком расплывчатой формулировкой.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[70]: C++0x начали урезать
От: jazzer Россия Skype: enerjazzer
Дата: 11.02.08 08:23
Оценка: +1
Здравствуйте, Andrei F., Вы писали:

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


E>>С удовольствием посмотрел бы на ваш вариант этого списка.


AF>Для меня основная задача интеропа — возможность вызывать legacy-код из моего кода. В C++/CLI эта задача решена хорошо. Таким образом, по этому пункту — серьезное преимущество у C++/CLI, а по обратной задаче (вызов нового кода из legacy-кода) мы имеем паритет.


Кстати, связка С++ + Python (при помощи Boost.Python) работает весьма хорошо в обе стороны, если не касаться шаблонов, естественно (ибо их не существует в рантайме). Т.е. нет проблем нагенерить иерархий классов С++, потом продолжить эти иерархии классами в Python, и затем звать их друг из друга почти как угодно (т.е. без извратов типа сравнения typeid) и в Питоне, и в С++ (и даже пробрасывать исключения, представляющие классы в Питоне, из одного питовского класса в другой, при том что оба отнаследованы от сишных классов)
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[72]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.08 12:38
Оценка: -1
Здравствуйте, Andrei F., Вы писали:

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


E>>Выделенное является слишком расплывчатой формулировкой.


AF>Если тебе не нравится моя формулировка — предлагай свою.


Дело не в формулировках, дело в конкретных примерах. Вызов методов crypto++ из D это одно, использование ACE_Reactor -- другое, а размещение на формочке в VB ActiveX элемента -- третье. Хотя везде legacy-код и везде интероперабильность. Так что примеры хотелось бы услышать.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[58]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.08 13:02
Оценка: :)
Здравствуйте, VladD2, Вы писали:

E>>Eiffel же стоит столько, что в бывшем Союзе мало кто может себе его позволить использовать в разработках. Так что же ты хотел на русскоязычном форуме?


VD>Ага. За Студию по $10 000 на одно раб.место платят, а Эйфиль позволить не моут. Слишком крут видмо он.


Ах да, я забыл. Ведь все разработчики учавствуют в проектах со сметой от $10M, работают на VS за $10K и получают от $5K в месяц. Совсем из головы вылетело.

E>>Я задавал вопросы по Eiffel здесь: eiffel_software -- отвечали достаточно грамотно и оперативно. Хотя и фанатики типа тебя, там так же встречались.


VD>Ты меня путашь с кем-то. Я реалист. А вот ты сказочник. Даже не сказочник, а сказочный герой. Придумал себе мир и недоволен, что другие в него не верят.


Ну да я понял. Проекты объемом в 2M строк и продажами в десятки тысяч копий для Nemerle не нужны. Ну вообще. Масштаб не тот. Мировым господством не пахнет.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: C++0x *крик души*
От: Cyberax Марс  
Дата: 23.02.08 01:37
Оценка: +1
Здравствуйте, kov_serg, Вы писали:

_>*мдя* как так, какого на%%% он тогда нужен. если в стандарте не будет много поточности. щас все системы идут по пути распараллеливания и переходя на плаформы не x86, а тут её нет да еще и только в 2009.

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

С точки зрения прикладного программиста — ничего особо серьезного.

_>Сборщик мусора -- вы серьёзно, и без него жили. Но зато, наверняка, добавят новых гвоздей в крышку гроба языка C. Первые два гвозди + + к языку C уже были потом добавились указатели на члены класса, SFINAE, появился stl и boost.

Указатели на члены класса — полезная вещь. Хотя сделали их и не очень красиво.

_>Все эти навороты только убивают язык. Такое ощущение что люди не отдают себе отчета и пытаются рекурсивно добавлять всякие рюшечки, навороты и изврещения. То что сделал Александреску ... просто слов нет, это операции на глазах через анальное отверстие, а теперь это делают стандартом. А товарищи из буста нагородили такого... да, это конешно всё замечательно, но это всё построено на заплатках и надстройках и ошибках в работе с шаблонами в разных компиляторах. И еще непонимаю эту манию писать длинные namespace-ы с деситикратной вложенностью как в яве. Зачем?.

Затем же, зачем и в Java — убрать столкновения имён.

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

И что? Я спокойно использовал Boost ещё когда не особо понимал тонкости метапрограммирования. Точно так же, не каждый новый программист на какой-нибудь Java понимает все тонкости работы библиотек, что не мешает ему ими пользоваться.

_>3. все готорвые решения имеющиеся в boost и stl ведут как ни странно к деградации программистов. находятся люди которые не удалить в строке скобочки средствами stl. не смотря на то что на языку C эта проблемма решается двумя строчками кода. Люди даже не знают как устроены сбалансированные деревься. Бегают итератором по мапам и удаляют элементы и недоумевают почему глючит. Даже поиск максимума превращается в тяжелейшую неразрешимую проблемму без всех этих мягких и удобных средств stl в которых они не ориентируются. Все эти плюшевые подушечки и готовые решения превращают язык C++ в быдлокодерский язык. И ведут к привыканию к комфортным

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

Неконструктивно.

Те же map/vector/list в С++, кстати, работают логическ ну точно так же, как и в куче других языков.

_>4. С введением столь сложного стандарта, никому в голову не придёт писать свой компилятор C++0x и выживут только компиляторы основанные на старых C++ наследуя все косяки и грабли заложенные в них. Вообще-то это тоже очень печально. Т.к. есть огромное число процессоров и микроконтроллеров для которых язык типа C++ был бы не заменим, особенно в условиях много поточности. Но там толь asm и в лучшем случае C. т.к. это очень простые для написания компиляторы.

Написание компилятора С++ для платформы, на которой есть компилятор С — задача достаточно простая (спросите у Комо-С++). Естественно, если не портировать всякие RTTI и исключения.

_>5. и еще все библиотеки как-то нацелены на совершенно общие задачи, и никак не нацелены на упрощение решения типовых задач и на повышения читабельности и выразительности кода. Почему в boost.threads не команды sleep(double seconds)? неужели столь ненужная функция. А эта любось к лямда вычислениям -- я досих пор не понимаю какого -- в каких практических задачах без этого нельзя обойтись?

Это ты про "static void boost::thread::sleep(const xtime& xt);"? У нее, кстати, наносекундное разрешение на поддерживаемых системах...

_>2 описывает пошагово что надо сделать для решения задачи

_>3 описывает что есть и что надо получить, а 1-ый сам ищет алгоритм для решения задачи
_>3' описывает взаимосвязи и события в системе (и может быть использован для проверки правильности работы программы или для синтеза схем как в программируемой логике)
Это всё только на бумаге выглядит хорошо. А на практике выливается в:
1) Ужас, разрушение и VisualBasic.
2) Непонятную смесь контролов.
3) Жуткое смешение слоёв.
Sapienti sat!
Re[2]: C++0x *крик души*
От: kov_serg Россия  
Дата: 23.02.08 12:51
Оценка: :)
Я не говорю об отдельных недостатках. Я хочу сказать что движемся не туда.

а теперь по мелочи:

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

в виде _begin_thred и pthread_* -- это просто каменный век. Всё остальное это не стандарт это сторонние библиотеки!
Я говорю о поддержке многопоточности в стандарте языка. Иначе все кому не лень пользуются кто чем. Почему? Видимо то что существует уже
мнооооого лет не устраивает. И вообще много поточность это не просто набор методов для запуска потоков, процессов и фиберов.
Это еще поддержка модели памяти с обектами которые следят за количеством ссылок на них. И синхронизация и обмен данными.
И прозрачно описанный способ завершения потока. Например выкидывание исключения из функций синхронизации или ожидания.
Много всего. Чего приходиться или искать или заниматься велосипедостроением.

>С точки зрения прикладного программиста — ничего особо серьезного.

Неужели. И как обычно решаются например обработка сигнала на завершение потока в C++, где поддерка TLS ?
Самое прикольное что если в Linux у вас поток поделил на ноль то это просто катострофа а если обратился по NULL то конец света.
О какой многопоточности может идти речь. А между прочим все эти проблеммы можно решить именно комптлятором и не валить на ось что там нет нормальной поддержки SEH.

>Указатели на члены класса — полезная вещь. Хотя сделали их и не очень красиво.

Некрасиво! да руки за такое отрывать надо

>Затем же, зачем и в Java — убрать столкновения имён.

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

>>креслам. А расслабляться не стоит. Враг не дремлет.

>И что? Предлагается убрать все библитеки и писать всё целиком с нуля?
Нет конешно. Просто констатирую факт. Но всё должно быть в языке естествено, а не так как щас. Приходится изучать кучу всего по большому счету совершенно ненужного. Что бы сделать элементарные вещи.

> Написание компилятора С++ для платформы, на которой есть компилятор С — задача достаточно простая (спросите у Комо-С++). Естественно, если не портировать всякие RTTI и исключения.

Не смешите мои тапочки! Попробуй как-нибуть, я на тебя посмотрю. Языки C для микроконтроллеров почти все не способны переварить то что генерит Комо-С++ (болле того он еще и не бесплатный и распостронять ты его не сможешь). И потом Комо стандарт поддерживает не идеально.

>Это ты про "static void boost::thread::sleep(const xtime& xt);"? У нее, кстати, наносекундное разрешение на поддерживаемых системах...

какая нафиг разница какое у неё разрешение. почему нет функции double getSleepPrecision();? почему просто нельзя сделать простую и понятную функцию void sleep(double dt)? и потом не заморачиваясь писать sleep(25e-6); ??? и нафига ей префикс boost::thread:: ?? это модно? или это придаёт чусво приобщения к вечности? код становиться короче и нагляднее если ей передавать не интервал, а конкретную дату?

>Это всё только на бумаге выглядит хорошо. А на практике выливается в:

>1) Ужас, разрушение и VisualBasic.
>2) Непонятную смесь контролов.
>3) Жуткое смешение слоёв.
Я об этом и говорю, и чем дальше тем хуже и хуже. Мы уже имеем убогий язык C# и C++.NET VisualBasic уже давно не Basic (это же был язык для начинающих, а щас это основной язык быдлокодерства для аспшного веба). слово VisualBasic можно считать ругательством.

>Просто придирка: в Яве нет вложенных пространств имён.

Посмотри исходники openOffice
Re[5]: C++0x *крик души*
От: Cyberax Марс  
Дата: 23.02.08 21:39
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

C>>со Стандартом компилятор.

AVK>О как, с большой буквы. Это по типу как Библия?
Сокращения имени собственного — названия "Стандарт ISO-IEC <номер-такой-то>".
Sapienti sat!
Re[13]: боязнь float и double
От: dr.Chaos Россия Украшения HandMade
Дата: 26.02.08 14:51
Оценка: :)
kov_serg wrote:

> Здравствуйте, dr.Chaos, Вы писали:

>
> DC>Типы с плавающей точкой на пустом месте создают море тонких моментов
> DC>(граблей), и если нет жёсткой необходимости их использовать, то лучше
> DC>обойтись вычислениями с фиксированной точкой.
> Я не понимаю, откуда такая фобия? Почему вы боитесь одних алгоритмов, при
> этом используете другие менее отлаженные и оптимизированные без зазрения
> совести.

:/ Мда-а-а. А откуда ты узнал какие алгоритмы я использую? Мелофон? Или со
спутника узрел? При чём тут алгоритмы? Значения с плавающей точкой
значительно более капризны при вычислениях, хотя бы потому, что вычисления
с ними не точные, за счёт представления. Я не вижу смысла использовать их
бездумно.

> DC>Короче, это я к тому, что пихать float везде очень неразумно.

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

Да ну? А с чем ещё?

> А вторая -- этого типа нет в стандарте, и всегда приходится пользовать

велосипед. Почему нельзя тип fixed (16.16) добавить в стандарт на ряду с
float и double? Интересно что мешает?

Да и float с double поддерживаются на довольно низком уровне. А
универсального решения всё равно не напишешь, т.к. области могут быть очень
разными.
Posted via RSDN NNTP Server 2.1 beta
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
C++0x начали урезать
От: Andrei F.  
Дата: 09.11.07 14:10
Оценка:
http://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!330.entry
Похоже, что сборки мусора и/или многопоточности в стандарте не будет, а сам стандарт будет выпущен в лучшем случае в 2009 году. Результат вполне закономерный, я не удивлен.
Re: C++0x начали урезать
От: Cyberax Марс  
Дата: 09.11.07 14:15
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>http://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!330.entry

AF>Похоже, что сборки мусора и/или многопоточности в стандарте не будет, а сам стандарт будет выпущен в лучшем случае в 2009 году. Результат вполне закономерный, я не удивлен.
То есть? Вроде бы написано, что многопоточность они собираются принять, а для GC собираются сделать только чтобы он был возможен.
Sapienti sat!
Re[2]: C++0x начали урезать
От: astral_marine  
Дата: 09.11.07 16:32
Оценка:
Здравствуйте, Cyberax, Вы писали:
C>... для GC собираются сделать только чтобы он был возможен.

А разве его сейчас нельзя реализовать? По-моему уже есть работающие реализации.
Re[3]: C++0x начали урезать
От: Cyberax Марс  
Дата: 09.11.07 16:37
Оценка:
Здравствуйте, astral_marine, Вы писали:

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

C>>... для GC собираются сделать только чтобы он был возможен.
_>А разве его сейчас нельзя реализовать? По-моему уже есть работающие реализации.
Только консервативный (т.е. мегахак).
Sapienti sat!
Re[2]: C++0x начали урезать
От: Andrei F.  
Дата: 09.11.07 17:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


-concepts (a way to write constraints for templates that lets us get way better error messages, overloading, and general template usability)
-advanced concurrency libraries (e.g., thread pools and reader-writer locks)
-garbage collection

Probably the biggest thing we did at this meeting was to choose time over scope: We decided that we can't ship C++0x without concepts, but we can and will ship without some or all of the other two.

То есть наверно какая-то поддержка многопоточности будет, но что из нее они посчитают "advanced" — это еще большой вопрос.
Re[3]: C++0x начали урезать
От: Cyberax Марс  
Дата: 10.11.07 07:36
Оценка:
Andrei F. wrote:
> То есть наверно какая-то поддержка многопоточности будет, но что из нее
> они посчитают "advanced" — это еще большой вопрос.
Лично для меня это вполне нормально. Я лучше буду самопальные пулы
потоков использовать, заточеные под мою задачу. Самое главное — чтобы
сделали основные примитивы многопоточности и написали внятную модель памяти.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[4]: C++0x начали урезать
От: Andrei F.  
Дата: 10.11.07 07:57
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Самое главное — чтобы

C>сделали основные примитивы многопоточности и написали внятную модель памяти.

тоже еще не факт
Re[5]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.11.07 16:40
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


C>>Самое главное — чтобы

C>>сделали основные примитивы многопоточности и написали внятную модель памяти.

AF>тоже еще не факт


Сами-то хоть Саттера прочитали или же только первых два абзаца?

What we voted into draft C++0x

Here is a list of the main features we voted into the C++0x working draft at this meeting, with links to the relevant papers to read for more information.

nullptr (N2431)
...

Explicit conversion operators (N2437 and N2434)
...

Concurrency memory model (N2429)

As I wrote in "The Free Lunch Is Over", chip designers and compiler writers "are under so much pressure to deliver ever-faster CPUs that they’ll risk changing the meaning of your program, and possibly break it, in order to make it run faster." This only gets worse in the presence of multiple cores and processors.

A memory model is probably of the lowest-level treaty between programmers and would-be optimizers, and fundamental for any higher-level concurrency work. Quoting from my memory model paper: "A memory model describes (a) how memory reads and writes may be executed by a processor relative to their program order, and (b) how writes by one processor may become visible to other processors. Both aspects affect the valid optimizations that can be performed by compilers, physical processors, and caches, and therefore a key role of the memory model is to define the tradeoff between programmability (stronger guarantees for programmers) and performance (greater flexibility for reordering program memory operations)."

Atomic types (N2427)

Closely related to the memory model is the feature of atomic types that are safe to use concurrently without locks. In C++0x, they will be spelled "atomic<T>". Here's a sample of how to use them for correct (yes, correct!) Double-Checked Locking in the implementation of a singleton Widget:

atomic<Widget*> Widget::pInstance = 0;

Widget* Widget::Instance() {
if( pInstance == 0 ) { // 1: first check
lock<mutex> hold( mutW ); // 2: acquire lock (crit sec enter)
if( pInstance == 0 ) { // 3: second check
pInstance = new Widget(); // 4: create and assign
}
} // 5: release lock
return pInstance; // 6: return pointer
}

Threading library (N2447)

You might have noticed that the above example used a lock<mutex>. Those are now in the draft standard too. C++0x now includes support for threads, various flavors of mutexes and locks, and condition variables, along with some other useful concurrency helpers like an efficient and portable std::call_once.


Это то, что уже включено в черновой вариант стандарта, в отличии от пулов нитей и reader-writter синхронизирующих примитивов.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: C++0x начали урезать
От: Andrei F.  
Дата: 11.11.07 08:34
Оценка:
Здравствуйте, eao197, Вы писали:

E>Сами-то хоть Саттера прочитали или же только первых два абзаца?


В опере часть страницы почему-то обрезалась.

E>Это то, что уже включено в черновой вариант стандарта, в отличии от пулов нитей и reader-writter синхронизирующих примитивов.


А где события, асинхронные вызовы?
Re[7]: C++0x начали урезать
От: Cyberax Марс  
Дата: 11.11.07 08:37
Оценка:
Здравствуйте, Andrei F., Вы писали:

E>>Это то, что уже включено в черновой вариант стандарта, в отличии от пулов нитей и reader-writter синхронизирующих примитивов.

AF>А где события, асинхронные вызовы?
События — это что? Про асинхронные вызовы (future<T>) написано, что они могут не пройти.
Sapienti sat!
Re[8]: C++0x начали урезать
От: Andrei F.  
Дата: 11.11.07 15:04
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>События — это что?


то, что в WinAPI называется event

C>Про асинхронные вызовы (future<T>) написано, что они могут не пройти.


Значит, скорее всего и не пройдут.
Re[9]: C++0x начали урезать
От: Cyberax Марс  
Дата: 11.11.07 15:10
Оценка:
Andrei F. wrote:
> C>События — это что?
> то, что в WinAPI называется event
По-моему, вполне должны быть.

> C>Про асинхронные вызовы (future<T>) написано, что они могут не пройти.

> Значит, скорее всего и не пройдут.
Не беда, их можно самому легко сделать.

Вообще, мне большая стандартная библиотека в С++ все равно не очень-то
нравится. Хотя бы потому, что с ней опять будет куча проблем с мелкими
несовместимостями между компиляторами. С Boost/ACE я хотя бы знаю, что
оно себя одинаково вести себя везде будет.

Ну и сторонние библиотеки эволюционируют быстрее. Например, кто
использует систему локализации, в STL?
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re: C++0x начали урезать
От: jazzer Россия Skype: enerjazzer
Дата: 11.11.07 15:54
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>http://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!330.entry

AF>Похоже, что сборки мусора и/или многопоточности в стандарте не будет, а сам стандарт будет выпущен в лучшем случае в 2009 году.

А на сайт комитета не пробовал смотреть?
Вот тут, например, много ссылок с цитатами: http://rsdn.ru/forum/message/2711910.1.aspx
Автор: jazzer
Дата: 30.10.07


AF>Результат вполне закономерный, я не удивлен.

Не понимаю иронии.
Я вот лично был бы крайне удивлен, если б Саттер вдруг написал, что окончательный стандарт выходит в следующем месяце, и в него войдут все существующие предложения и все существующие баги будут пофикшены.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[10]: C++0x начали урезать
От: igna Россия  
Дата: 11.11.07 22:43
Оценка:
Здравствуйте, Cyberax, Вы писали:

C> С Boost/ACE я хотя бы знаю, что оно себя одинаково вести себя везде будет.


Это да. TAO 1.4a (ACE 5.4) при компиляции в Visual Studio 6.0 совершенно одинаково, то есть независимо от установленного SP3, SP5 или SP6, приводит к аварийному завершению при закрытии Visual Studio. И это еще ничего, хоть компиляция и сборка успешно заканчиваются, при попытке же скомпилировать ACE 5.5 + TAO 1.5 VS 6.0 просто падает напрочь и не шевелится.
Re[9]: C++0x начали урезать
От: vdimas Россия  
Дата: 12.11.07 09:29
Оценка:
Здравствуйте, Andrei F., Вы писали:

C>>События — это что?


AF>то, что в WinAPI называется event


Это просто семафор со счётчиком = 1
Вроде так он и реализован в винде, т.е. если будет примитив-семафор, то все остальные делаются тонкой прослойкой в либе.
Re[3]: C++0x начали урезать
От: BulatZiganshin  
Дата: 07.12.07 18:38
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>PS кстати, что меня удивляет в последнее время — это количество малолетних кулхацкеров, которые с восторгом пишут по форумам что-нибудь типа "оооо, С++ — это так круто, там все так сложно! C# и Java это вааще отстой, там все просто и проги никогда не валятся. А вот в C++ чуть что и сразу GPF, ууу, как круто" Видимо, таким вот будет новое поколение плюсовиков


меня точно так же удивляют преданные пользователи языков без автоматического полиморфизма, т-ех, где надо явно писать типы, нет лямбд и не поддерживается point-free programming style
Люди, я люблю вас! Будьте бдительны!!!
Re[4]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.12.07 15:33
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>меня точно так же удивляют преданные пользователи языков без автоматического полиморфизма, т-ех, где надо явно писать типы, нет лямбд и не поддерживается point-free programming style


Другими словами тебя смущают Русские, Англечане и те кто пользуется SQL?
Мне даже трудно представить о чем идет речь. Видимо о Китайском.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.12.07 15:34
Оценка:
Здравствуйте, Sni4ok, Вы писали:

S>то что не будет GC- слава богу, иначеб сделали из языка- помойку.

S>А насчёт многопоточности- пофиг, буст он и в линуксе буст.

Ага. Что водка, что пулимет. Лиш бы с ног валило.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.12.07 13:44
Оценка:
Здравствуйте, Cyberax, Вы писали:

VD>>Дык там тупо сделали два языка. Один С++, а другой не очень.

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

Это да. Но Ди тут вроде как не обсуждался, а на то чтобы так радикально доработать язык Страуструп и комитет не пойдут. По крайне мере не пойдут на то чтобы тупо взять решение МС. А если они пойдут своим путем, то две шестнадцатиричные декады не хватит.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: C++0x начали урезать
От: WolfHound  
Дата: 10.12.07 14:35
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Что именно не стыкуется? Классический семафор именно вручную и устанавливается, как иначе? Установка этого семафора — это сброс самого события. Этот автосброс можно сделать одной лишней строчкой кода-обёртки.

Учи матчасть.
Ибо под семафор может зайти только N=const потоков. Для того чтобы вошол новый старй должен выйти. Просто по определению.
А через этот примитив может пройти сколько угодно потоков.
Ну и где тут семафор?

V>Еще раз, все примитивы синхронизации делаются на семафорах, принципиально,

В теории любой примитив синхронизации можно выразить через любой другой примитив синхронизации.
Но на практике так никто не делает ибо тормозит.
А чтобы не тормозило каждый примитив синхронизации выпиливают под конкретную железку.

V>Это к теме не относится, т.к. однофигственно применимо к любым примитивам синхронизации.

Очень даже относится.
Ибо не смотря на теорию на практике все делать через семофоры это дурь полная ибо тормоза.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: C++0x начали урезать
От: WolfHound  
Дата: 11.12.07 13:27
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Самому не стыдно?

Мне нет.
А вот тебе должно быть.
Ибо если говорить о auto-reset event то это действительно семафор.
А вот manual-reset event ведет себя сильно иначе.

V>Потрать пять минут и пофантазируй.

Сам потрать.

V>Намекну — ты всё правильно говоришь, именно, что кто-то должен "выйти", представь семафор объектом с методами enter(int timeout) и exit() и распиши событие на нём. Достаточно сделать допущение, что exit() выполняется из произвольного треда, что есть по факту, т.к. классический семафор — это структура, не запоминающая идентификаторы потоков.

У классического семафора есть 3 операции:
1)init(int count)
2)enter — если лимит исчерпан ждет пока ктонибудь скажет exit
3)exit
У manual reset event 4 операции
1)init(bool state)
2)set — никогда не блокирует
3)reset — никогда не блокирует
4)wait — блокирует если состояние reset пропускает если состояние set
Ну и где тут семафор?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: C++0x начали урезать
От: vdimas Россия  
Дата: 11.12.07 18:29
Оценка:
Здравствуйте, WolfHound, Вы писали:


V>>Самому не стыдно?

WH>Мне нет.
WH>А вот тебе должно быть.
WH>Ибо если говорить о auto-reset event то это действительно семафор.
WH>А вот manual-reset event ведет себя сильно иначе.

Точно сильно?

V>>Потрать пять минут и пофантазируй.

WH>Сам потрать.

using System;
using System.Threading;

namespace SemaphoreProbe
{
    // обёртка над виндовозным
    internal class ClassicSemaphore
    {
        private Semaphore sem;

        public ClassicSemaphore(int max) { sem = new Semaphore(max, max); }
        public void Enter() { sem.WaitOne(); }
        public void Exit() { sem.Release(); }
        // Dispose() - лень 
    }

    // целевой класс
    internal class Event {
        private ClassicSemaphore sem = new ClassicSemaphore(1);

        // семафор-наоборот
        public Event() { sem.Enter(); }
        public virtual void Wait() { Reset(); Set(); }
        public void Set() { sem.Exit(); }
        public void Reset() { sem.Enter(); }
    }

    internal class AutoresetEvent : Event {
        public override void Wait() { Reset(); }
    }

    // демонстрация
    internal class Program {
        private static volatile Event ev1;
        private static volatile bool finish = false;

        private static void Main() {
            Console.WriteLine("Autoreset Event Test:\n");
            ev1 = new AutoresetEvent();

            for (int i = 0; i < 10; i++)
                new Thread(ThreadProcAutoreset).Start();

            for (int i = 0; i < 10; i++) {
                Thread.Sleep(1);
                ev1.Set();
            }

            finish = true;
            for (int i = 0; i < 10; i++)
                ev1.Set();
            finish = false;

            Console.WriteLine("\nManual Reset Event Test:");
            ev1 = new Event();

            for (int i = 0; i < 10; i++)
                new Thread(ThreadProcManual).Start();

            for (int i = 0; i < 5; i++) {
                Console.Write("\nSignaled: ");
                ev1.Set();
                Thread.Sleep(1);
                ev1.Reset();
                Console.WriteLine();
            }

            finish = true;
            ev1.Set();
        }

        private static void ThreadProcAutoreset()
        {
            while (!finish) {
                ev1.Wait();
                if (!finish)
                    Console.WriteLine("Autoreset #" + Thread.CurrentThread.ManagedThreadId);
            }
        }

        private static void ThreadProcManual()
        {
            while (!finish) {
                ev1.Wait();
                if (!finish)
                    Console.Write("#" + Thread.CurrentThread.ManagedThreadId + " ");
            }
        }
    }
}



V>>Намекну — ты всё правильно говоришь, именно, что кто-то должен "выйти", представь семафор объектом с методами enter(int timeout) и exit() и распиши событие на нём. Достаточно сделать допущение, что exit() выполняется из произвольного треда, что есть по факту, т.к. классический семафор — это структура, не запоминающая идентификаторы потоков.

WH>У классического семафора есть 3 операции:
WH>1)init(int count)
WH>2)enter — если лимит исчерпан ждет пока ктонибудь скажет exit
WH>3)exit
WH>У manual reset event 4 операции
WH>1)init(bool state)
WH>2)set — никогда не блокирует
WH>3)reset — никогда не блокирует
WH>4)wait — блокирует если состояние reset пропускает если состояние set
WH>Ну и где тут семафор?

все вызовы event — блокирующие, просто в состоянии "signaled" блокировка сразу отпускается. Поэкспериментируй с затратами на WaitOne() виндового евента в сигнальном состоянии.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[16]: C++0x начали урезать
От: WolfHound  
Дата: 11.12.07 18:34
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Точно сильно?

Угу.

public virtual void Wait() { Reset(); Set(); }

Данная операция не атомарна.
Я уже молчу о нескольких Set или Reset подряд.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: C++0x начали урезать
От: vdimas Россия  
Дата: 11.12.07 20:23
Оценка:
Здравствуйте, WolfHound, Вы писали:



WH>
WH>public virtual void Wait() { Reset(); Set(); }
WH>

WH>Данная операция не атомарна.

Уверен? Хинт: счётчик равен 1.

WH>Я уже молчу о нескольких Set или Reset подряд.


Я предвидел этот вопрос, потому и посоветовал поэкспериментировать с "родным" event и его WaitOne() в сигнальном состоянии.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[18]: C++0x начали урезать
От: WolfHound  
Дата: 11.12.07 21:08
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Я предвидел этот вопрос, потому и посоветовал поэкспериментировать с "родным" event и его WaitOne() в сигнальном состоянии.

И что там можно наэксперементировать?

Кстати запустил твой код на двуядерной машине.
Autoreset Event Test:

Autoreset #4
Autoreset #5
Autoreset #4
Autoreset #12
Autoreset #4
Autoreset #12
Autoreset #4
Autoreset #12
Autoreset #4

Unhandled Exception: System.Threading.SemaphoreFullException: Adding the given count to the semaphore would cause it to exceed its maximum count.
   at System.Threading.Semaphore.Release(Int32 releaseCount)
   at System.Threading.Semaphore.Release()
   at SemaphoreProbe.ClassicSemaphore.Exit() in c:\work\ConsoleApplication5\Program.cs:line 13
   at SemaphoreProbe.Event.Set() in c:\work\ConsoleApplication5\Program.cs:line 25
   at SemaphoreProbe.Program.Main() in c:\work\ConsoleApplication5\Program.cs:line 56

чтд.

Эксперемены с несколькими Set'ами и Reset'ами привели к вылетам и зависаниям соответственно.
После переделки на настоящие Event'ы
    internal class Event
    {
        private System.Threading.EventWaitHandle event_;
        public Event()
        {
            event_ = Create();
        }

        protected virtual System.Threading.EventWaitHandle Create()
        {
            return new System.Threading.ManualResetEvent(true);
        }

        public virtual void Wait() { event_.WaitOne(); }
        public void Set() { event_.Set(); }
        public void Reset() { event_.Reset(); }
    }

    internal class AutoresetEvent : Event
    {
        protected override System.Threading.EventWaitHandle Create()
        {
            return new System.Threading.AutoResetEvent(true);
        }
    }

вылеты (в том числе с несколькими Set'ами и Reset'ами подряд) прекратились
однако начались зависания... что и не удивительно ибо см на ManagedThreadId'ы в твоем варианте.
после изменения кода
        private static void ThreadProcAutoreset()
        {
            ev1.Wait();
            Console.WriteLine("Autoreset #" + Thread.CurrentThread.ManagedThreadId);
        }

тест начал завершаться
Autoreset Event Test:

Autoreset #3
Autoreset #5
Autoreset #4
Autoreset #7
Autoreset #9
Autoreset #8
Autoreset #10
Autoreset #12
Autoreset #11
Autoreset #6

Manual Reset Event Test:
#13 #13 #13 #13 #13 #13 #13 #13 #13 #13 #13 #13 #13 #14 #13 #13 #14 #14 #14 #14 #14 #13 #15 #15 #14 #14 #14 #14 #14 #14 #14 #14 #14 #16 #16 #16 #16 #13 #13 #16
 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #18 #18 #16 #16 #18 #18 #18 #14 #14 #14 #16 #14 #1
4 #16 #16 #14 #14 #16 #16 #14 #14 #16 #16 #16 #16 #16 #16 #16 #16 #16 #17 #17 #17 #17 #17 #17 #14 #14 #14 #14 #17 #17 #17 #13 #13 #14 #14 #14 #14 #13 #13 #13 #
13 #13 #14 #14 #14 #14 #14 #14 #14 #14 #16 #16 #16 #18 #18 #18 #14 #14 #18 #18 #14 #14 #18 #18 #14 #14 #14 #14 #14 #14 #14 #14 #14 #13 #13 #16 #16 #16 #16 #16
#16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #16 #19 #19 #19 #19 #19 #19 #19 #19 #16 #19 #19 #16
 #16 #16 #16 #16 #16 #19 #19 #19 #20 #19 #19 #20 #20 #20 #20 #20 #20 #18 #15 #15 #15 #15 #14 #14 #14 #14 #14 #15 #15 #15 #16 #16 #16 #16 #16 #15 #15 #17 #17 #1
7 #17 #16 #16 #16 #16 #17 #17 #17 #17 #20 #20 #20 #20 #20 #20 #17 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #
20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #21 #21 #21 #14 #14 #14 #14 #22 #22 #22 #22 #22 #22 #22 #16 #16 #22 #22 #22 #22 #22 #22 #22 #22 #17 #17 #17
Signaled: #17 #16 #18 #18 #18 #18 #21 #21 #21 #21 #21 #16 #21 #21 #16 #16 #16 #16 #21 #21 #16 #16 #16 #13 #13 #13 #13 #13 #22 #13 #13 #22 #22 #22 #22 #13 #13 #
22 #22 #22 #22 #22 #16 #17 #14 #18

Signaled: #22 #22 #22 #22 #22 #22 #22 #22 #20

Signaled: #21 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #21 #20 #21 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #21 #21 #14 #20 #13 #
19 #16 #15

Signaled: #21 #21 #21 #21 #14 #19 #14 #19 #14 #14 #19 #14 #14 #14 #20 #14 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20 #20

Signaled: #20 #20 #20 #18 #18 #18 #18 #18 #18 #18 #18 #22 #18 #19 #18 #18 #18 #18 #18 #18 #19 #19 #19 #14 #14
#19 #16 #20 #13 #22 #17 #15 #18 #21


Короче иди учи матчасть.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 11.12.07 22:11
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


VD>Наивняк ты, однако.

VD>Этому стандарту не зра присвоили номер 0х. Это же шеснадцатиричный префикс, так что в него можно записать любую фиру от 0 до F. А при очень большом желании можно записать и две-три цифры.
VD>Так что 9-ы год — это не очень реальная дата. Вот A-F — это более реальный срок. За одно можно преурочить выход нового стандарта к какому-нибудь юбилею. Например, к столетию Страутрупа.


Хотя бы язык вначале бы выучил на базовом уровне. Шестнадцатиричные константы начинаются с префикса 0х. Если х рассматривать как плейсхолдер, то тут префикс 0. А с префикса 0 начинаются восьмеричные константы. Т.ч. максимум, что может быть, это — 07.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 11.12.07 22:13
Оценка:
Здравствуйте, Sni4ok, Вы писали:

S>Здравствуйте, Andrei F., Вы писали:


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


S>то что не будет GC- слава богу, иначеб сделали из языка- помойку.

S>А насчёт многопоточности- пофиг, буст он и в линуксе буст.


Бусту далеко до того, что будет в языке. В бусте нет:

# memory model
# atomics library




1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[19]: C++0x начали урезать
От: vdimas Россия  
Дата: 12.12.07 02:07
Оценка:
Здравствуйте, WolfHound, Вы писали:


WH>[/c#]

WH>вылеты (в том числе с несколькими Set'ами и Reset'ами подряд) прекратились
WH>однако начались зависания... что и не удивительно ибо см на ManagedThreadId'ы в твоем варианте.

В них как раз всё чудесно

WH>после изменения кода


Угу, обрезал суть — у тебя не попадёт дважды один и тот же тред на евент в первом варианте, а хотелось убедиться во всех сценариях прохода через евент, т.е. чтобы тред, получивший квант времени, опять застрял на AutoResetEvent в цикле. Там же очевидная причина возможных зависаний и вылетов — "грязный" способ завершения тредов в Main().

WH>чтд.


Угу, на стек-трейс посмотри

В моём упрощённом примере реализации евента на семафоре есть недостаток — в том, что нельзя вызывать Set когда и так уже в signaled state, и Reset если уже сброшен, т.к. я хотел лишь продемонстрировать логику выражения евента через семафор (ведь об этом шёл спор). Подобный многократный Set/Reset требует доп. флаг состояния в любом случае и синхронизация доступа к этому флагу.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[3]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.12.07 06:36
Оценка:
Здравствуйте, remark, Вы писали:

R>Хотя бы язык вначале бы выучил на базовом уровне. Шестнадцатиричные константы начинаются с префикса 0х. Если х рассматривать как плейсхолдер, то тут префикс 0. А с префикса 0 начинаются восьмеричные константы. Т.ч. максимум, что может быть, это — 07.


Чем поучать других занялся бы собственным чувством юмора, которое у тебя явно приплюсплюснуто.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: C++0x начали урезать
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 12.12.07 08:12
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Забавно. Т.е. повторять одно и тоже на разные лады — это признак хорошего чувства юмора:
здесь римские цифры
Автор: VladD2
Дата: 21.09.06
, здесь множество xxx
Автор: VladD2
Дата: 17.10.05
. Теперь шестнадцатеричный префикс...
Re[7]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 12.12.07 11:55
Оценка:
Здравствуйте, remark, Вы писали:

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


VD>>А вообще, вы ребяты совсем неадекватны. Не стоит ассоциировать себя с языком на котором вам приходится писать.

VD>>На оборот надо адекватно оцинивать обстановку. Вы используете марально устаревший, кривой язык. Используете потому что других не знаете или потому, что работу только на нем дают. Первое проблема вашего образования (и ее стоит исправить), второе проблема рынка (и с ней ничего не поделаеть). При таком подходе издевки над С++ уже не будут задевать вас за живое. Вот берите пример с Вольфхаунда. Он отлично знает С++ и использует его на работе, так как это требование работадателя. Однако оценивает язык совершенно адекватно.


R>Хммм.... Похоже ты его боишься...

R>Иначе почему вообще столько внимания и желания унизить такую "кривую" и "бесполезную" штуку?


Человек склонен бояться неизвестного


R>


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: C++0x начали урезать
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 12.12.07 12:05
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А вообще, вы ребяты совсем неадекватны. Не стоит ассоциировать себя с языком на котором вам приходится писать.

VD>На оборот надо адекватно оцинивать обстановку. Вы используете марально устаревший, кривой язык. Используете потому что других не знаете или потому, что работу только на нем дают. Первое проблема вашего образования (и ее стоит исправить), второе проблема рынка (и с ней ничего не поделаеть). При таком подходе издевки над С++ уже не будут задевать вас за живое. Вот берите пример с Вольфхаунда. Он отлично знает С++ и использует его на работе, так как это требование работадателя. Однако оценивает язык совершенно адекватно.

Ещё есть проблема предметной области. Мне, например, из С++ больше всего необходимы классы + шаблоны (без наследования и виртуальных функций). Ну не хочу я всё это на чистом С или ассемблере делать — лишней писанины будет куча. А всякие .Net или JVM не подходят принципиально. Во я и слежу за развитием своего рабочего инструмента, аналогов которому пока не вижу. Что же здесь неадекватного.
Re[7]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.12.07 12:48
Оценка:
Здравствуйте, remark, Вы писали:

R>Хммм.... Похоже ты его боишься...


Ага. Страшен он як смерть лютая .

R>Иначе почему вообще столько внимания


Сколько? Заговорили о нем вот все.

R>и желания унизить такую "кривую" и "бесполезную" штуку?


"Бесполезным" я его не называл. Любой ЯП полный по Тьюрингу можно применять для разработки ПО.
Ну, а кривой и марально устаревший — это не унижение, а констатация факта. Иначе что вообще было говорить о новой версии?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.12.07 12:48
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Ещё есть проблема предметной области. Мне, например, из С++ больше всего необходимы классы + шаблоны (без наследования и виртуальных функций). Ну не хочу я всё это на чистом С или ассемблере делать — лишней писанины будет куча. А всякие .Net или JVM не подходят принципиально. Во я и слежу за развитием своего рабочего инструмента, аналогов которому пока не вижу. Что же здесь неадекватного.


А что за задачи, если не секрет?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: C++0x начали урезать
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 12.12.07 12:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А что за задачи, если не секрет?


Разного рода обработка видео в системе видеонаблюдения. В данный момент это детектирование и разпознавание движущихся объектов.
Re[12]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 12.12.07 15:05
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>А вот если есть нетривиальная обработка, то тут точно С++ не лучший помошник.



Почему?!



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[11]: C++0x начали урезать
От: Cyberax Марс  
Дата: 13.12.07 05:05
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>А как же скорость? Куча вычислений, многократные проходы по изображению, получение видео от WDM-драйверов, работа с DirectDraw поверхностями... Слава богу, что с новыми процессорами постепенно из кода ассемблерные вставки убираются.

N>С С++ всё понятно. На нём (и на С ещё) такие задачи решались и решаются. И библиотек на нём много — те же интеловские OpenCV и IPP.
Совсем сильно вычислительный код на OCaml'е писать плохо — все же оптимизирует он математику не так здорово, как Intel C++ или даже MSVC. С целой арифметикой там тоже определенные заморочки есть.
Sapienti sat!
Re[12]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 13.12.07 08:41
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>Совсем сильно вычислительный код на OCaml'е писать плохо — все же оптимизирует он математику не так здорово, как Intel C++ или даже MSVC. С целой арифметикой там тоже определенные заморочки есть.

И с многопоточностью у него неочень — GC не многопоточный.
Re[14]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 13.12.07 11:23
Оценка:
Здравствуйте, remark, Вы писали:

C>>>Совсем сильно вычислительный код на OCaml'е писать плохо — все же оптимизирует он математику не так здорово, как Intel C++ или даже MSVC. С целой арифметикой там тоже определенные заморочки есть.

EC>>И с многопоточностью у него неочень — GC не многопоточный.
R>А до предложенной модели памяти и сопутствующей библиотеки поддержки вообще всем ныне существующим языкам далеко.
Ага — язык прикольный во многих отношениях, но необходимо ещё учитывать и специфику задачи.
Re[10]: C++0x начали урезать
От: ironwit Украина  
Дата: 13.12.07 11:29
Оценка:
VladD2 пишет:
> В ОКамле как раз параметрический полиморфизм на всшем уровне реализован.
> И классы есть. А еще есть не менее полезные вещи как лямбды с
> замыканиями, автоматический вывод типов, сборщик мусора, алгероические

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

заранее спасибо за культурный ответ
Posted via RSDN NNTP Server 2.1 beta
Я не умею быть злым, и не хочу быть добрым.
Re[7]: C++0x начали урезать
От: no4  
Дата: 13.12.07 12:16
Оценка:
Здравствуйте, VladD2, Вы писали:

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


C>>Как в C++/CLR, например. Который, кстати, остается единственным

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

VD>Дык там тупо сделали два языка. Один С++, а другой не очень.


Ну, мне кажется, С++/CLI это два языка а MC++ больше был похож на C++ с новой "управляемой" семантикой включаемой модификаторами. Правда микрософтовцам не понравилось, что он слишком похож и его разделили на два (крышечки эти...)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.12.07 12:51
Оценка:
Здравствуйте, ironwit, Вы писали:

I>простите неумелому

I>какой плюс в реальном проекте приносит "автоматический вывод типов"?
I>может я зря его не применяю?

Там не только вывод типов. Там еще и система типов с возможностями остуствующими в С++ есть. А вывод типов дает урощение кода и уменьшение его объема. В некоторых задачах, особенно связанных с анализом и распознаванием, можно получить до 10 раз. Уж в 2-3 раза код будет точно меньше.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.12.07 12:51
Оценка:
Здравствуйте, EvilChild, Вы писали:

R>>А до предложенной модели памяти и сопутствующей библиотеки поддержки вообще всем ныне существующим языкам далеко.

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

Это ты про новый стандарт С++?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: C++0x начали урезать
От: Константин Л. Франция  
Дата: 13.12.07 14:03
Оценка:
Здравствуйте, VladD2, Вы писали:

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


I>>простите неумелому

I>>какой плюс в реальном проекте приносит "автоматический вывод типов"?
I>>может я зря его не применяю?

VD>Там не только вывод типов. Там еще и система типов с возможностями остуствующими в С++ есть. А вывод типов дает урощение кода и уменьшение его объема. В некоторых задачах, особенно связанных с анализом и распознаванием, можно получить до 10 раз. Уж в 2-3 раза код будет точно меньше.


прости Влад, но это не всегда так. Я когда игрался с макросами Nemerle, приходилось читать код макросов из Nemerle.Compiler если не ошибаюсь. Так вот из-за отсутствия intellisense читать такой код было мучительно:


def ts = typer.TypeExpr(start);        
def tyVar = ts.Type;
def hint = tyVar.Hint;        
def startTypeInfo = hint.Value.TypeInfo;        
def endTypeInfo = typer.TypeExpr(end).Type.Hint.Value.TypeInfo;
def endType = endTypeInfo.SystemType;


Рефлектором бегал по сигнатурам, чтобы понять возвращаемый тип. Может быть я что-то делал не так, но без IDE это смерть.
Re[16]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 13.12.07 14:43
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Это ты про новый стандарт С++?


Про OCaml.
Re[12]: C++0x начали урезать
От: ironwit Украина  
Дата: 13.12.07 15:03
Оценка:
VladD2 пишет:

> I>простите неумелому

> I>какой плюс в реальном проекте приносит "автоматический вывод типов"?
> I>может я зря его не применяю?
>
> Там не только вывод типов. Там еще и система типов с возможностями
> остуствующими в С++ есть. А вывод типов дает урощение кода и уменьшение
> его объема. В некоторых задачах, особенно связанных с анализом и
> распознаванием, можно получить до 10 раз. Уж в 2-3 раза код будет точно
> меньше.

Влад. ну ты блин Ваааще
рассказал достаточно красиво, но можешь привести просто обычный
конкретный пример? я просто лучше конкретику понимаю ...
Posted via RSDN NNTP Server 2.1 beta
Я не умею быть злым, и не хочу быть добрым.
Re[8]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.12.07 16:01
Оценка:
Здравствуйте, no4, Вы писали:

no4>Ну, мне кажется, С++/CLI это два языка а MC++ больше был похож на C++ с новой "управляемой" семантикой включаемой модификаторами. Правда микрософтовцам не понравилось, что он слишком похож и его разделили на два (крышечки эти...)


Дык в MC++ и проблем хватало. И все равно даже MC++ тоже четко разделял управляемые ссылки и обычные.

Собственно — это, похоже, единственный правильный путь. Проблема только в том, что тогда в С++ появляется концептуально другой подязык "Безопастный C++". А это цепляет за себя целую кучу концепций. Так что итоге получится что-то вроде MC++ + .NET. Причем если МС создал эталонную реализацию, то в случае со стандартом — это будет куча разных и не новых языков. Так что в стандарт C++ прийдется встраивать и бинарную составляющую.

Короче от C++ ничего не останется.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.12.07 16:01
Оценка:
Здравствуйте, EvilChild, Вы писали:

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


VD>>Это ты про новый стандарт С++?


EC>Про OCaml.


Тогда бось, ты не верно понял remark-а. Он то про новые (гипотетические) мегафичи С++ говорил. Ну, мол ща им обомится и будут они в шоколаде... как эта как ту дуру из Дома 2 завут?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.12.07 16:01
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>прости Влад, но это не всегда так. Я когда игрался с макросами Nemerle, приходилось читать код макросов из Nemerle.Compiler если не ошибаюсь. Так вот из-за отсутствия intellisense читать такой код было мучительно:


КЛ>
КЛ>def ts = typer.TypeExpr(start);        
КЛ>def tyVar = ts.Type;
КЛ>def hint = tyVar.Hint;        
КЛ>def startTypeInfo = hint.Value.TypeInfo;        
КЛ>def endTypeInfo = typer.TypeExpr(end).Type.Hint.Value.TypeInfo;
КЛ>def endType = endTypeInfo.SystemType;
КЛ>


Ну, не мучительнее чем бустовский, првада?

А вывод типов из инициализации и в С++ введут. Они вроде его как в Ди "auto" хотят назвать. Чтобы ключевое слово повторно использовать.

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

КЛ>Рефлектором бегал по сигнатурам, чтобы понять возвращаемый тип. Может быть я что-то делал не так, но без IDE это смерть.


Это с не привычки. К тому же IDE решает проблему на раз. Незнаю тоольк есть ли для обычного ОКамла добротные IDE. Но есть для F#, а он обратно совместим с ОКамлом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 13.12.07 16:40
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Это ты про новый стандарт С++?


EC>>Про OCaml.


VD>Тогда бось, ты не верно понял remark-а. Он то про новые (гипотетические) мегафичи С++ говорил. Ну, мол ща им обомится и будут они в шоколаде... как эта как ту дуру из Дома 2 завут?


Я расценил его слова как скепсис насчёт OCaml'а в задачах очень критичных по производительности,
т.е. тех, где битовыжимание оправдано — OCaml плюсам там не конкурент.
now playing: Braincell — Linguist
Re[14]: C++0x начали урезать
От: Константин Л. Франция  
Дата: 13.12.07 17:40
Оценка:
Здравствуйте, VladD2, Вы писали:

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


КЛ>>прости Влад, но это не всегда так. Я когда игрался с макросами Nemerle, приходилось читать код макросов из Nemerle.Compiler если не ошибаюсь. Так вот из-за отсутствия intellisense читать такой код было мучительно:


КЛ>>
КЛ>>def ts = typer.TypeExpr(start);        
КЛ>>def tyVar = ts.Type;
КЛ>>def hint = tyVar.Hint;        
КЛ>>def startTypeInfo = hint.Value.TypeInfo;        
КЛ>>def endTypeInfo = typer.TypeExpr(end).Type.Hint.Value.TypeInfo;
КЛ>>def endType = endTypeInfo.SystemType;
КЛ>>


VD>Ну, не мучительнее чем бустовский, првада?


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

VD>А вывод типов из инициализации и в С++ введут. Они вроде его как в Ди "auto" хотят назвать. Чтобы ключевое слово повторно использовать.


Введут, и я от этой фичи не в восторге. Разве что для foreach полезна

VD>Но я тут немного о другом выводе типов говорил. Немерлу он не доступен по причине неподходящей системы типов. Я говорил о выводе обобщенных реализаций фунций. ОКамл это делать умеет. У него, правда, свои грабли. У них, например, операторы арифметические не перегруженные. Для плавающей точки используют .+, а для целых просто +. Но, зато, если в фунции используются только ссылки на фунции переданные в качестве параметров, то ОКамл выводит фунцию как полиморфную. При этом никаких параметров типов указывать не нужно.


Я не в курсе что такое обобщенные реализации функций.

КЛ>>Рефлектором бегал по сигнатурам, чтобы понять возвращаемый тип. Может быть я что-то делал не так, но без IDE это смерть.


VD>Это с не привычки. К тому же IDE решает проблему на раз. Незнаю тоольк есть ли для обычного ОКамла добротные IDE. Но есть для F#, а он обратно совместим с ОКамлом.


Если бы решало, то я бы не бегал Рефлектором.
Re[14]: C++0x начали урезать
От: WolfHound  
Дата: 13.12.07 19:10
Оценка:
Здравствуйте, remark, Вы писали:

R>А мне вот это
Автор: remark
Дата: 01.01.07
очень понравилось.

R>Визуально вроде код на С на несколько вспомогательных строчек длиннее, но по сути один в один с Немерле.
Влад на это еще тогда ответил...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: C++0x начали урезать
От: WolfHound  
Дата: 13.12.07 19:27
Оценка:
Здравствуйте, FR, Вы писали:

FR>С (*.с *.h) 194 kb

FR>Ocaml (*.nw) 222 kb
FR>(я еще не копался что там внутри так что если кто раскопает и разъяснит почему буду рад)
На первый взгляд в коде на Ocaml очень сильно больше комментариев чем в сишном коде.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: C++0x начали урезать
От: FR  
Дата: 13.12.07 20:10
Оценка:
Здравствуйте, palm mute, Вы писали:

PM>Тебя не насторожило странное расширение *.nw для исходников на Окамле? Окамловская реализация использует NoWeb, систему literate programming. Загляни внутрь и прикинь на глазок количество комментариев.


Я заглядывал и показалось что что-то не так
Вот как бы выкусить оттуда комментарии незнаешь? Там вроде целый препроцессор на перле используется, так что в лоб скриптиком похоже не выйдет.
А на глаз их оценить тяжело.
Re[14]: C++0x начали урезать
От: ironwit Украина  
Дата: 14.12.07 07:30
Оценка:
VladD2 пишет:

> I>Влад. ну ты блин Ваааще

> I>рассказал достаточно красиво, но можешь привести просто обычный
> I>конкретный пример? я просто лучше конкретику понимаю ...
>
> Лезут тут разные, а потом вещи пропадают (с).
>
> Это вообще-то не для тебя писалось.
> Человек у которого в списке интересов Эрланг стоит сам кому хочешь
> должен все рассказать.
так я с ним еще не все понял
только в последней версии добавили имитацию работы драйверов написанных
на сторонних языках так, как будто они сделаны в ерланге (если я верно
понял)
а у меня все драйвера на delphi
>
> А если кому интересны примеры, то путь лезут куда-нить вроде
> http://ocaml.spb.ru и смотрят. Вот только боюсь, что для чистого
> С++-ника это будет все одно что книжки на китайском. По крайней мере я
> раньши это именно так и понимал.

ок. полез но я ещё вернусь
Posted via RSDN NNTP Server 2.1 beta
Я не умею быть злым, и не хочу быть добрым.
Re[15]: C++0x начали урезать
От: Курилка Россия http://kirya.narod.ru/
Дата: 14.12.07 07:35
Оценка:
Здравствуйте, ironwit, Вы писали:

I>VladD2 пишет:


>> Человек у которого в списке интересов Эрланг стоит сам кому хочешь

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

Речь про Эрланг? Если да, то непонятно откуда "имитация", а ports и erl_interface уже очень давненько наличествуют, если не с самого начала.
Думаю перевести сишные хэдэры на паскаль нет очень большой проблемы, другое дело, что драйвер "вообще" и эрланговый — очень разные вещи.
Re[16]: C++0x начали урезать
От: FR  
Дата: 14.12.07 10:05
Оценка:
Здравствуйте, palm mute, Вы писали:

PM>Получаем разницу в 2 раза, что и требовалось доказать.


Угу, похоже реально к этому и будет близко. Хотя код на ML все равно будет красивше и читабельней, он все таки во многом DSL для компиляторострения
Re[16]: C++0x начали урезать
От: ironwit Украина  
Дата: 14.12.07 10:13
Оценка:
Курилка пишет:
> Здравствуйте, ironwit, Вы писали:
>
> I>VladD2 пишет:
>
>> > Человек у которого в списке интересов Эрланг стоит сам кому хочешь
>> > должен все рассказать.
> I>так я с ним еще не все понял
> I>только в последней версии добавили имитацию работы драйверов написанных
> I>на сторонних языках так, как будто они сделаны в ерланге (если я верно
> I>понял)
> I>а у меня все драйвера на delphi
>
> Речь про Эрланг? Если да, то непонятно откуда "имитация", а ports и
> erl_interface уже очень давненько наличествуют, если не с самого начала.
> Думаю перевести сишные хэдэры на паскаль нет очень большой проблемы,
> другое дело, что драйвер "вообще" и эрланговый — очень разные вещи.

я говорил про это
The Erlang driver API has been extended with a portable POSIX thread 
like API for multi-threading. The Erlang driver thread API provides: 
threads, mutexes, condition variables, read/write locks, and 
thread-specific data. For more information see the erl_driver(3) 
documentation.

с http://www.erlang.org/doc/highlights.html
но если в чем то напутал то прошу извинить..., читал обьявление о релизе
на лету, и просто поставил в голове галочку что чтото в ерланге с
драйверами поменялось, надо бы почитать подробнее. вскользь проглянул
про erl_driver(3) documentation, понял что напутал.
Posted via RSDN NNTP Server 2.1 beta
Я не умею быть злым, и не хочу быть добрым.
Re[17]: C++0x начали урезать
От: Курилка Россия http://kirya.narod.ru/
Дата: 14.12.07 10:20
Оценка:
Здравствуйте, ironwit, Вы писали:

I>я говорил про это

I>
I>The Erlang driver API has been extended with a portable POSIX thread 
I>like API for multi-threading. The Erlang driver thread API provides: 
I>threads, mutexes, condition variables, read/write locks, and 
I>thread-specific data. For more information see the erl_driver(3) 
I>documentation.
I>

I>с http://www.erlang.org/doc/highlights.html
I>но если в чем то напутал то прошу извинить..., читал обьявление о релизе
I>на лету, и просто поставил в голове галочку что чтото в ерланге с
I>драйверами поменялось, надо бы почитать подробнее. вскользь проглянул
I>про erl_driver(3) documentation, понял что напутал.

Ну изменения есть, факт, меня "сторонние языки" смутили
А про потоки есть инфа здесь
Кстати, может быть у меня тоже появятся задачи код дельфовый интегрить с Эрлангом в следующем году
Re[16]: C++0x начали урезать
От: FR  
Дата: 14.12.07 10:37
Оценка:
Здравствуйте, palm mute, Вы писали:

PM>Получаем разницу в 2 раза, что и требовалось доказать.


Еще здесь есть неплохие картинки показывающий размер кода (притом оптимизированного на скорость) для разных языков, правда там не компиляторы, а более общий код, что для меня интересней. Разница между ML образными и C++ как раз в полтора — два раза.
Re[15]: C++0x начали урезать
От: WolfHound  
Дата: 14.12.07 12:38
Оценка:
Здравствуйте, remark, Вы писали:

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

R>Это наталкивает на мысли...
О том что код писался как пример...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 13:21
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


R>>И то, что вот это аналогичный мега-убогий, на 2 порядка худший, принципиально неподдерживаемый код на С++:

R>>
R>> case expr::Call:
R>>     if ("max" == e.name) Math.Max(e.arg1, e.arg2);
R>>     else if ("min" == e.name) Math.Min(e.arg1, e.arg2);
R>>     else throw InvalidOperationException(e);
R>>

WH>Нет никаких arg1 и arg2. Вторым параметром идет список. Также нужно вычслить выражения перед тем как их скормить Min/Max
WH>Те как минимум должно быть так:
WH>
WH>    case expr::Call:
WH>        if ("max" == e.name && e.args.size() == 2) Math.Max(eval(e.args[0]), eval(e.args[1]));
WH>        else if ("min" == e.name && e.args.size() == 2) Math.Min(eval(e.args[0]), eval(e.args[1]));
WH>        else throw InvalidOperationException(e);
WH>



Ну это только в таких развитых языках как немерле. А на С++ достаточно и этого:
 case expr::Call:
     if ("max" == e.name) Math.Max(e.intArg1, e.intArg2);
     else if ("min" == e.name) Math.Min(e.intArg1, e.intArg2);
     else throw InvalidOperationException(e);




WH>И это весьма примитивный пример.

WH>При попытке повторить это у тебя будет ужасное нагромаждение кода
WH>
WH>| Call (OpCode ("=="), [nested_cond,
WH>    Parm where (expr = TExpr.TypeConversion(TExpr.Literal(Literal.Bool(true)), _, _))], _) =>
WH>    emit_branch(nested_cond.expr, else_label)
WH>


Так это и тут выглядит как "ужасное нагромаждение кода". То, что это удалось запихнуть в 3 строчки, не является показателем хорошести кода. Вполне возможно, что я предпочёл запись этого кода в 10 строк.



R>>Кстати, у меня, например, возникают вопросы к некому ".Eval()" в примере на немерле? Уж не убица ли это типизации?

R>>И не замена union'ам?
R>>А что, если я опишусь и напишу "name.Eval()", при этом в name по счастливому стечению обстоятельств лежит нечто похожее на число?

Тут беру слова обратно — не разобрался, что такое Eval()


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

WH>Они объективны нравится это тебе или нет.
WH>Ибо код на на С сложен для поддержки и восприятия. Код на С практически не контролирует компилятор.
WH>Что скажет компилятор если ты ошибешься с индексами или забудешь else throw ?
WH>Да ничего он не скажет.
WH>И на тестовых примерах вероятно все отработает.
WH>А у клиента все свалится.


Писать на С я не призываю. Я лично пишу на С++ и мне нравится. Компилятор контролирует код не меньше, чем в других современных языках, а учитывая распространённость С++, возможно, что и больше.
Индексы я использую редко. Что будет, если ошибусь? Исключение или ассёрт скорее всего. Вообще индексы я использую редко. Они сами по себе провоцируют ошибки. Обнаружение большинства ошибок я стараюсь переносить на фазы компиляции/линковки/стартапа. Имхо смысл иметь исключение, где по сути должен быть ассёрт не много.
Если забуду "else throw" — компилятор предупреждает от неполных switch, отсутствии return, неопределённых виртуальных функциях.
Код на немерле не падает "у клиента"? Даже если неправильно указать индекс?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[15]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.07 13:25
Оценка:
Здравствуйте, Константин Л., Вы писали:

VD>>Ну, не мучительнее чем бустовский, првада?


КЛ>А я его не читаю. Только хэдэра. От имплементации иногда не по себе, но это случается раз в полгода.


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

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

К тому же, если тебе нужно ты можешь уточнять типы вручную. Считашь что это повысит читабельность? Вперед...

Лично я когда разбираюсь с нетривиальными кусками даже не поддержкой IDE пользуюсь, а отладчиком. Там все типы известны. Более того там известны реальные данные и можно протросировать неясные участки. Это урощает понимание кода на любом языке.

VD>>А вывод типов из инициализации и в С++ введут. Они вроде его как в Ди "auto" хотят назвать. Чтобы ключевое слово повторно использовать.


КЛ>Введут, и я от этой фичи не в восторге. Разве что для foreach полезна


Зря. Привыкнешь немного и поймешь, что это удбобно.

КЛ>Я не в курсе что такое обобщенные реализации функций.


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

КЛ>Если бы решало, то я бы не бегал Рефлектором.


А вот Рефлектор на Немерле падает.
Ну, и очень советую не Рефлектор использовать, а отладчик. Рефлекто он иногда помогает при отладке не тривиальных макросов. И то это от убогости родных тулзов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.07 13:25
Оценка:
Здравствуйте, remark, Вы писали:

R>Это наталкивает на мысли...


Мысли — это полезно .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: C++0x начали урезать
От: ironwit Украина  
Дата: 14.12.07 13:31
Оценка:
Курилка пишет:
>
> Ну изменения есть, факт, меня "сторонние языки" смутили
> А про потоки есть инфа здесь
> <http://www.erlang.org/doc/man/erl_driver.html#ErlDrvTid&gt;
> Кстати, может быть у меня тоже появятся задачи код дельфовый интегрить с
> Эрлангом в следующем году
во. класс
порассказываешь много страшного?
Posted via RSDN NNTP Server 2.1 beta
Я не умею быть злым, и не хочу быть добрым.
Re[19]: C++0x начали урезать
От: Курилка Россия http://kirya.narod.ru/
Дата: 14.12.07 13:33
Оценка:
Здравствуйте, ironwit, Вы писали:

I>порассказываешь много страшного?


см. почту.
Re[18]: C++0x начали урезать
От: WolfHound  
Дата: 14.12.07 13:52
Оценка:
Здравствуйте, remark, Вы писали:

R>Ну это только в таких развитых языках как немерле. А на С++ достаточно и этого:

R>
R> case expr::Call:
R>     if ("max" == e.name) Math.Max(e.intArg1, e.intArg2);
R>     else if ("min" == e.name) Math.Min(e.intArg1, e.intArg2);
R>     else throw InvalidOperationException(e);
R>

Нет никаких intArg1 и intArg2. Call содержит список ибо функции бывают с разным колличеством ургуметов.

R>Так это и тут выглядит как "ужасное нагромаждение кода". То, что это удалось запихнуть в 3 строчки, не является показателем хорошести кода. Вполне возможно, что я предпочёл запись этого кода в 10 строк.

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

R>Писать на С я не призываю. Я лично пишу на С++ и мне нравится. Компилятор контролирует код не меньше, чем в других современных языках, а учитывая распространённость С++, возможно, что и больше.


Бред.
А выделеное полный бред.
Ибо распростаненность языка никак не влияет на его систему типов.

R>Индексы я использую редко. Что будет, если ошибусь? Исключение или ассёрт скорее всего. Вообще индексы я использую редко. Они сами по себе провоцируют ошибки. Обнаружение большинства ошибок я стараюсь переносить на фазы компиляции/линковки/стартапа. Имхо смысл иметь исключение, где по сути должен быть ассёрт не много.

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

R>Если забуду "else throw" — компилятор предупреждает от неполных switch, отсутствии return, неопределённых виртуальных функциях.

Ну-ну. В данном случае никаких предупреждений не будет ибо в С++ не редко пишут код в котором намеренно пропускают выполнение за приделы case.

R>Код на немерле не падает "у клиента"? Даже если неправильно указать индекс?

Там небудет индексов на ровном месте.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: C++0x начали урезать
От: FR  
Дата: 14.12.07 13:52
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>Ну, не мучительнее чем бустовский, првада?


КЛ>>А я его не читаю. Только хэдэра. От имплементации иногда не по себе, но это случается раз в полгода.


VD>Дык по сложности решаемых задач ему до ядра компилятора далеко. Не странно, что без глубокого погружения в нем мало что понять можно.


Boost большой, там есть вполне сопоставимые по сложности с ядром компилятора вещи. Да и занимается во многом тем же самым эмуляцией высокоуровневых фич
Re[17]: C++0x начали урезать
От: Дьяченко Александр Россия  
Дата: 14.12.07 14:25
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>При попытке повторить это у тебя будет ужасное нагромаждение кода

WH>
WH>| Call (OpCode ("=="), [nested_cond,
WH>    Parm where (expr = TExpr.TypeConversion(TExpr.Literal(Literal.Bool(true)), _, _))], _) =>
WH>    emit_branch(nested_cond.expr, else_label)
WH>


Можно вопрос немного в сторону выделенное нельзя разве записать покороче с использованием квазицитирования?
Хотя бы
TExpr.Literal(Literal.Bool(true))
замениить на
<[ true ]>

?
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[19]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 15:03
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


R>>Ну это только в таких развитых языках как немерле. А на С++ достаточно и этого:

R>>
R>> case expr::Call:
R>>     if ("max" == e.name) Math.Max(e.intArg1, e.intArg2);
R>>     else if ("min" == e.name) Math.Min(e.intArg1, e.intArg2);
R>>     else throw InvalidOperationException(e);
R>>

WH>Нет никаких intArg1 и intArg2. Call содержит список ибо функции бывают с разным колличеством ургуметов.

union решает эту проблему — под каждый тип функции своё кол-во аргументов с нужными типами



R>>Так это и тут выглядит как "ужасное нагромаждение кода". То, что это удалось запихнуть в 3 строчки, не является показателем хорошести кода. Вполне возможно, что я предпочёл запись этого кода в 10 строк.

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


Во-первых, это не ровное место. Скорее всего тут содержится какая-то логика. Какая именно, к сожалению, не представляется возможным понять.
С С напротив, логика максимально прозрачная — есть только тривиальные конструкции. Именно поэтому С является "интернациональным" языком общения между разработчиками. Львиная доля всех алгоритмов и научных статей использует именно С (иногда С++, pascal, java), но никогда функциональные языки (если это только не статья по функциональным языкам), т.к. автор не хочет на ровном месте терять большую часть читателей.
Поэтому же С используют крупнейшие опен-сорц проекты — linux, postgresql и т.д.



R>>Писать на С я не призываю. Я лично пишу на С++ и мне нравится. Компилятор контролирует код не меньше, чем в других современных языках, а учитывая распространённость С++, возможно, что и больше.

WH>
WH>Бред.
WH>А выделеное полный бред.
WH>Ибо распростаненность языка никак не влияет на его систему типов.


Зато влияет на детектирование ошибок компилятором — о чём я и говорил.


R>>Если забуду "else throw" — компилятор предупреждает от неполных switch, отсутствии return, неопределённых виртуальных функциях.

WH>Ну-ну. В данном случае никаких предупреждений не будет ибо в С++ не редко пишут код в котором намеренно пропускают выполнение за приделы case.


Я привык больше верить своим глазам:

warning: enumeration value `x3' not handled in switch



R>>Код на немерле не падает "у клиента"? Даже если неправильно указать индекс?

WH>Там небудет индексов на ровном месте.

Какая разница на каком месте? На любом месте что будет?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[16]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.07 15:40
Оценка:
Здравствуйте, remark, Вы писали:

R>И не замена union'ам?


Ага. Варианты это замена юнионам. Вот только типобезопасная и удобная.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.07 15:55
Оценка:
Здравствуйте, FR, Вы писали:

FR>Boost большой,


Ага. Закрывает слишком много дырок языка.

FR> там есть вполне сопоставимые по сложности с ядром компилятора вещи. Да и занимается во многом тем же самым эмуляцией высокоуровневых фич


Можно смело утверждать, что он проще просто потому, что не все фичи он эмулирует.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.07 15:55
Оценка:
Здравствуйте, remark, Вы писали:

R>union решает эту проблему — под каждый тип функции своё кол-во аргументов с нужными типами


Ага. И вносит другую. Каждое обращение к юниону может положить программу, так как акромя внимания разработчика от ошибок с ним ничего уберечь не может.

Вот решиш ты изменить код и сделать 3 параметра вместо 2, забудешь сделать это в одном из мест и "пиши приплыли". А с вариантами таких проблем нет. Они не только типобезопасны (их просто нельзя использовать некорректно), но компилятор еще контролирует их использование. Так что он сам подскажет где следует сделать изменения.

R>Зато влияет на детектирование ошибок компилятором — о чём я и говорил.


Поверь на слово. ОКамл или Немрел выявляет на порядок больше ошибок во время компиляции. И в этих языках вообще нет возможности писать код который испортит память или сделает другую бяку. Так что количество ошибок при прграммировании на них просто не сопоставимо с оным при программировании на С++. Это качествнно разный уровень.

R>Я привык больше верить своим глазам:

R>

R>warning: enumeration value `x3' not handled in switch

Скажи, какой к черту switch если у тебя было else throw?
И какой к черту enumeration если ты строки сравниваешь?

ЗЫ

Ты начал изворачиваться. Это хороший показатель того, что ты и сам понимашь, что не прав.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: C++0x начали урезать
От: Константин Л. Франция  
Дата: 14.12.07 16:45
Оценка:
Здравствуйте, VladD2, Вы писали:

[]

VD>Лично я когда разбираюсь с нетривиальными кусками даже не поддержкой IDE пользуюсь, а отладчиком. Там все типы известны. Более того там известны реальные данные и можно протросировать неясные участки. Это урощает понимание кода на любом языке.


Лезть в отладчик для определения типа это мощно. Вот вам и вывод типов (про такие же проблемы в с++ знаю, так что это палка о двух концах).

[]

VD>А вот Рефлектор на Немерле падает.


редко, но бывало

VD>Ну, и очень советую не Рефлектор использовать, а отладчик. Рефлекто он иногда помогает при отладке не тривиальных макросов. И то это от убогости родных тулзов.


Использовать отладчик для борьбы с выводом типов? Мдя...

ПС: я не против вывода типов. Просто вот не хочется пользоваться левыми тулзами, вместо того, чтобы прочитать аннотацию типа и спать спокойно.
Re[21]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 16:51
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>Я привык больше верить своим глазам:

R>>

R>>warning: enumeration value `x3' not handled in switch

WH>Код покажи.


enum X {x1, x2, x3};

int main()
{
  X x = x1;
  switch (x)
  {
    case x1: break;
    case x2: break;
  }
}



R>>

WH>Черезмерное употребление алкоголя вредит вашему здоровью.

1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[22]: C++0x начали урезать
От: WolfHound  
Дата: 14.12.07 17:04
Оценка:
Здравствуйте, remark, Вы писали:

R>
R>enum X {x1, x2, x3};

R>int main()
R>{
R>  X x = x1;
R>  switch (x)
R>  {
R>    case x1: break;
R>    case x2: break;
R>  }
R>}
R>

И как это относится к

забудешь else throw

Ы?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 14.12.07 17:10
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Concepts эту задачу решают. Некий аналог классов типов Хаскеля.
now playing: Braincell — Networks
Re[23]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 17:12
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>И как это относится к

WH>

забудешь else throw

WH>Ы?


Если забуду "else throw" — компилятор предупреждает от неполных switch, отсутствии return, неопределённых виртуальных функциях.



Стремянки из if-else-if не обязательно использовать вообще...



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[21]: C++0x начали урезать
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 14.12.07 17:46
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>Поэтому же С используют крупнейшие опен-сорц проекты — linux, postgresql и т.д.

WH> Они его используют исключительно по историческим причинам. Ну написали когдато пара ребятишек мега ОСь UNIX и для того чтобы ее было проще портировать написали переносимый ассемблер ака С. И все начали это безобразие куда попало переносить...
WH>Правда потом ребята поняли свои ошибки и сделали и болие другую ОСь и создали для этого болие другой язык но миллионы мух досихпор продолжают тащить то самое безобразие которое получилось у этих ребят в начале.

Можно про выделенное подробнее? Желательно, ссылки...
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[19]: C++0x начали урезать
От: Дьяченко Александр Россия  
Дата: 14.12.07 17:49
Оценка:
Здравствуйте, VladD2, Вы писали:

ДА>>Можно вопрос немного в сторону выделенное нельзя разве записать покороче с использованием квазицитирования?

ДА>>Хотя бы
TExpr.Literal(Literal.Bool(true))
замениить на
<[ true ]>

ДА>>?

VD>В Немерле квази-цитирование доступно только для PExpr, а Вольфхаунд использовал TExpr.


Про то что квази цитирование доступно только для PExpr что-то не сообразил.
А заменить
TExpr.TypeConversion(TExpr.Literal(Literal.Bool(true)), _, _))
на квази цитирование + преобразование PExpr -> TExpr или получится еще сложнее?

VD>И вообще, я думаю, что это просто пример.


Это кусок патча компилятора в файле ILEmitter который ты приводил в другой ветке (см. Re[11]: Принцип подстановки Барбары Лисков
Автор: VladD2
Дата: 01.01.07
ближе к концу).

VD>Да и что тут говорить о таких высших материях как квази-цитирование если ставится под сомнения ползность базовых вещей вроде вариантов и паттернм-матчинга? Квази-цитирование основано на них и без них оно будет просто не полноценно.

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

Не спорю, но я же говорил что вопрос немного в сторону.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[24]: C++0x начали урезать
От: WolfHound  
Дата: 14.12.07 18:16
Оценка:
Здравствуйте, remark, Вы писали:

R>

R>Если забуду "else throw" — компилятор предупреждает от неполных switch, отсутствии return, неопределённых виртуальных функциях.

R>Стремянки из if-else-if не обязательно использовать вообще...
Вот твой код:
case expr::Call:
     if ("max" == e.name) Math.Max(e.intArg1, e.intArg2);
     else if ("min" == e.name) Math.Min(e.intArg1, e.intArg2);
     else throw InvalidOperationException(e);

Переписывай без if-else-if ...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[25]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 19:11
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>
WH>case expr::Call:
WH>     if ("max" == e.name) Math.Max(e.intArg1, e.intArg2);
WH>     else if ("min" == e.name) Math.Min(e.intArg1, e.intArg2);
WH>     else throw InvalidOperationException(e);
WH>

WH>Переписывай без if-else-if ...


Да в принципе и так варнинг есть:

double eval(const expr* e)
{
    if (0 == strcmp("min", e->data.name) && 2 == e->data.count)
        return min(eval(e->data.params[0]), eval(e->data.params[1]));
    else if (0 == strcmp("max", e->data.name) && 2 == e->data.count)
        return max(eval(e->data.params[0]), eval(e->data.params[1]));
}


gcc:

control reaches end of non-void function


msvc:

'eval' : not all control paths return a value




1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[26]: C++0x начали урезать
От: WolfHound  
Дата: 14.12.07 19:19
Оценка:
Здравствуйте, remark, Вы писали:

R>Да в принципе и так варнинг есть:

R>
R>double eval(const expr* e)
R>{
R>    if (0 == strcmp("min", e->data.name) && 2 == e->data.count)
R>        return min(eval(e->data.params[0]), eval(e->data.params[1]));
R>    else if (0 == strcmp("max", e->data.name) && 2 == e->data.count)
R>        return max(eval(e->data.params[0]), eval(e->data.params[1]));
R>}
R>

Э нет... давай по взрослому.
Давай с несколькими опкодами, и чтобы Call был в свитче не первым.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[28]: C++0x начали урезать
От: WolfHound  
Дата: 14.12.07 20:05
Оценка:
Здравствуйте, remark, Вы писали:

А так?
double eval(const expr* e)
{
    switch (e->t)
    {
    case expr::Call:
        if (0 == strcmp("min", e->data.name) && 2 == e->data.count)
            return min(eval(e->data.params[0]), eval(e->data.params[1]));
        else if (0 == strcmp("max", e->data.name) && 2 == e->data.count)
            return max(eval(e->data.params[0]), eval(e->data.params[1]));
    case expr::Plus:
        return 0;
    }
}
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 16.12.07 09:30
Оценка:
Здравствуйте, EvilChild, Вы писали:

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


VD>>>>Это ты про новый стандарт С++?


EC>>>Про OCaml.


VD>>Тогда бось, ты не верно понял remark-а. Он то про новые (гипотетические) мегафичи С++ говорил. Ну, мол ща им обомится и будут они в шоколаде... как эта как ту дуру из Дома 2 завут?


EC>Я расценил его слова как скепсис насчёт OCaml'а в задачах очень критичных по производительности,

EC>т.е. тех, где битовыжимание оправдано — OCaml плюсам там не конкурент.


Эффективная синхронизация это не о битовыжимании. Это о различии в производительности на порядки и о принципиальной способности к масштабированию.
Естественно это не относится к скриптам командной строки. А вот к компиляторам уже может относиться. Если распараллеливание идёт на уровне компиляции функций исходного кода, это составляет достаточно мелкозернистый параллелизм, и издержки на синхронизацию могут начать превышать полезную работу, плюс масштабируемость может оказаться со знаком минус. Хороший вопрос для размышления — почему MSVC распараллеливает компиляцию исключительно на уровне проектов, но даже не на уровне файлов.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[21]: C++0x начали урезать
От: Стэн http://stanonwork.blogspot.com/
Дата: 16.12.07 23:16
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>Поэтому же С используют крупнейшие опен-сорц проекты — linux, postgresql и т.д.

WH> Они его используют исключительно по историческим причинам. Ну написали когдато пара ребятишек мега ОСь UNIX и для того чтобы ее было проще портировать написали переносимый ассемблер ака С. И все начали это безобразие куда попало переносить...
WH>Правда потом ребята поняли свои ошибки и сделали и болие другую ОСь и создали для этого болие другой язык но миллионы мух досихпор продолжают тащить то самое безобразие которое получилось у этих ребят в начале.
То-то я смотрю на исходники Inferno и вижу, что все написано на С. И даже компилятор Limbo на C...
А ты, на мой взгляд, здесь смешиваешь две очень разные задачи — способ создания инструмента, и способ использования инструмента.

Вот чем реально могут помочь в задаче написания ядра операционной системы (ОС) такие языки как Nemerle или C#, которые работают поверх .NET? Конечно, можно на C# написать всю логику ядра ОС — планировщик процессов, управление ресурсами, загрузку/выгрузку программ, но как запускать это ядро? На .NET не запустишь, так как она не работает поверх голого железа (особенно нестандартного); брать какую-то микро-ОС, поверх которой запускать .NET, а на нем уже запускать нашу ОС... Это все хорошо, кроме того, что это не является решением поставленной задачи, так как задача состоит в том, чтобы написать упоминавшуюся микро-ОС (самую-самую базовую).

Можно попробовать скомпилировать программы на вышеупоминавшихся языках в native-код, однако это чисто теоритическая возможность, ведь, насколько я понимаю, официально с компиляцией .NET приложений в native-код есть некоторые сложности... Далее, я читало о ядре ОС, написанной на Haskell, но потом переписанном на C, так как на Haskell — медленно, и в Singularity ядро runtime'а на С/С++ написано... Даже Haskell (GHC), компилятор которого написан на Haskell, имеет RTS, написанную на С...

А теперь от задач абстрактных, к задачам конкретным. Сейчас я занимаюсь разработкой библиотеки асинхронного программирования act-o
Автор: Стэн
Дата: 27.11.07
. На данный момент она написана на C++ и используется только из C++. Не касаясь вопроса о том, что писать клиентские приложения на C++ — некошерно, обратимся к вопросу на чем писать runtime? Для новых эксперементальных runtime'ов я решил отказаться от С++ и писать на чистом C, так как он проще и дров наломать в нем сложнее... В связи с моральным устареванием С, как несколько раз я читал в этой теме, у меня вопрос — есть ли ему какая-то замена? Но только, чтобы программы компилировались в native-код, чтобы был полный и простой доступ к низкоуровневым API ОС и железу, чтобы программы получались быстрыми, и чтобы была возможность относительно легко портировать программы на разные ОС.
Re[21]: C++0x начали урезать
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 17.12.07 07:51
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


Видимо поэтому, Plan9 написанна на C?
Re[22]: C++0x начали урезать
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 17.12.07 13:38
Оценка:
Здравствуйте, Стэн, Вы писали:

С>Вот чем реально могут помочь в задаче написания ядра операционной системы (ОС) такие языки как Nemerle или C#, которые работают поверх .NET? Конечно, можно на C# написать всю логику ядра ОС — планировщик процессов, управление ресурсами, загрузку/выгрузку программ, но как запускать это ядро? На .NET не запустишь, так как она не работает поверх голого железа (особенно нестандартного); брать какую-то микро-ОС, поверх которой запускать .NET, а на нем уже запускать нашу ОС... Это все хорошо, кроме того, что это не является решением поставленной задачи, так как задача состоит в том, чтобы написать упоминавшуюся микро-ОС (самую-самую базовую).


Ну и, что ты хотел этим сказать? Что у C++ есть узкая ниша для написания загрузчиков managed-ОС? Ну так никто и не говорит, чтобы его выкинуть вообще. Но для написания 99% софта он и впрямь не очень-то подходит.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[22]: C++0x начали урезать
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.12.07 14:57
Оценка:
Здравствуйте, Стэн, Вы писали:
С>Вот чем реально могут помочь в задаче написания ядра операционной системы (ОС) такие языки как Nemerle или C#, которые работают поверх .NET? Конечно, можно на C# написать всю логику ядра ОС — планировщик процессов, управление ресурсами, загрузку/выгрузку программ, но как запускать это ядро?
Ядро компилируется в нативный код верифицирующим компилятором (см. тж. Bartok), и все дела.
Ты как-то невнимательно читал про Singularity. В его ядре:
Sing#: 90%
C++:    6%
x86asm: 4%
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: C++0x начали урезать
От: Стэн http://stanonwork.blogspot.com/
Дата: 17.12.07 15:26
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Здравствуйте, Стэн, Вы писали:


С>>Вот чем реально могут помочь в задаче написания ядра операционной системы (ОС) такие языки как Nemerle или C#, которые работают поверх .NET? Конечно, можно на C# написать всю логику ядра ОС — планировщик процессов, управление ресурсами, загрузку/выгрузку программ, но как запускать это ядро? На .NET не запустишь, так как она не работает поверх голого железа (особенно нестандартного); брать какую-то микро-ОС, поверх которой запускать .NET, а на нем уже запускать нашу ОС... Это все хорошо, кроме того, что это не является решением поставленной задачи, так как задача состоит в том, чтобы написать упоминавшуюся микро-ОС (самую-самую базовую).


K>Ну и, что ты хотел этим сказать? Что у C++ есть узкая ниша для написания загрузчиков managed-ОС?

Вообще-то, все что я хотел сказать, я сказал абзацем выше:

То-то я смотрю на исходники Inferno и вижу, что все написано на С. И даже компилятор Limbo на C...
А ты, на мой взгляд, здесь смешиваешь две очень разные задачи — способ создания инструмента, и способ использования инструмента.

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

K>Ну так никто и не говорит, чтобы его выкинуть вообще. Но для написания 99% софта он и впрямь не очень-то подходит.

Согласен. Просто я встретил несколько замечаний на тему, что мол С/С++ морально устаревшие языки, и решил обратить внимание, что есть области, где это далеко не так.
Re[23]: C++0x начали урезать
От: Стэн http://stanonwork.blogspot.com/
Дата: 17.12.07 15:34
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Стэн, Вы писали:

С>>Вот чем реально могут помочь в задаче написания ядра операционной системы (ОС) такие языки как Nemerle или C#, которые работают поверх .NET? Конечно, можно на C# написать всю логику ядра ОС — планировщик процессов, управление ресурсами, загрузку/выгрузку программ, но как запускать это ядро?
S>Ядро компилируется в нативный код верифицирующим компилятором (см. тж. Bartok), и все дела.
S>Ты как-то невнимательно читал про Singularity. В его ядре:
S>
S>Sing#: 90%
S>C++:    6%
S>x86asm: 4%
S>

Я читал этот абзац:

Like the previous Cedar [26] and Spin [4] projects, the Singularity project enjoys the safety and productivity benefits of writing a
kernel in a type-safe, garbage-collected language. Counting lines of code, over 90% of the Singularity kernel is written in Sing#.
While most of the kernel is type-safe Sing#, a significant portion of the kernel code is written in the unsafe variant of the language.
The most significant unsafe code is the garbage collector, which accounts for 48% of the unsafe code in Singularity. Other major
sources of unsafe Sing# code include the memory management and I/O access subsystems. Singularity includes small pockets of
assembly language code in the same places it would be used in a kernel written in C or C++, for example, the thread context
switch, interrupt vectors, etc. Approximately 6% of the Singularity kernel is written in C++, consisting primarily of the
kernel debugger and low-level system initialization code.

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

PS: А вот чего я действительно не заметил, так это конкретные значения количества строк кода на C/C++ и ASM?!
Re[7]: C++0x начали урезать
От: vdimas Россия  
Дата: 17.12.07 15:39
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Дык там тупо сделали два языка. Один С++, а другой не очень.


В одном выражении могут участвовать GC и не-GC типы, так что это скорее один язык, имеющий возможность работать с разными классами типов.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[23]: C++0x начали урезать
От: FR  
Дата: 18.12.07 08:03
Оценка:
Здравствуйте, remark, Вы писали:

R>Здравствуйте, Стэн, Вы писали:


С>>А теперь от задач абстрактных, к задачам конкретным. Сейчас я занимаюсь разработкой библиотеки асинхронного программирования act-o
Автор: Стэн
Дата: 27.11.07
. На данный момент она написана на C++ и используется только из C++. Не касаясь вопроса о том, что писать клиентские приложения на C++ — некошерно, обратимся к вопросу на чем писать runtime? Для новых эксперементальных runtime'ов я решил отказаться от С++ и писать на чистом C, так как он проще и дров наломать в нем сложнее... В связи с моральным устареванием С, как несколько раз я читал в этой теме, у меня вопрос — есть ли ему какая-то замена? Но только, чтобы программы компилировались в native-код, чтобы был полный и простой доступ к низкоуровневым API ОС и железу, чтобы программы получались быстрыми, и чтобы была возможность относительно легко портировать программы на разные ОС.



R>На немерле зато строк кода будет меньше. А на OCaml всё будет математически выверенно. Ну и что, что работать не будет


На OCaml будет работать, если бы не требование

простой доступ к низкоуровневым API ОС и железу

то Ocaml вполне подходит.
Re[24]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 18.12.07 08:41
Оценка:
Здравствуйте, FR, Вы писали:

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


R>>Здравствуйте, Стэн, Вы писали:


С>>>А теперь от задач абстрактных, к задачам конкретным. Сейчас я занимаюсь разработкой библиотеки асинхронного программирования act-o
Автор: Стэн
Дата: 27.11.07
. На данный момент она написана на C++ и используется только из C++. Не касаясь вопроса о том, что писать клиентские приложения на C++ — некошерно, обратимся к вопросу на чем писать runtime? Для новых эксперементальных runtime'ов я решил отказаться от С++ и писать на чистом C, так как он проще и дров наломать в нем сложнее... В связи с моральным устареванием С, как несколько раз я читал в этой теме, у меня вопрос — есть ли ему какая-то замена? Но только, чтобы программы компилировались в native-код, чтобы был полный и простой доступ к низкоуровневым API ОС и железу, чтобы программы получались быстрыми, и чтобы была возможность относительно легко портировать программы на разные ОС.



R>>На немерле зато строк кода будет меньше. А на OCaml всё будет математически выверенно. Ну и что, что работать не будет


FR>На OCaml будет работать, если бы не требование

простой доступ к низкоуровневым API ОС и железу

то Ocaml вполне подходит.



Можно ли трактовать такую фразу как-то ещё, кроме как:
Подходит, если не... == не подходит
?


А как, кстати, касательно производительности? Гарантий использования памяти? Возможности контролировать локальность размещения объектов в памяти?
Если есть GC — то тоже не подходит, т.к. скорее всего Стэн'у придётся заняться своим кастомным GC.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[25]: C++0x начали урезать
От: FR  
Дата: 18.12.07 08:53
Оценка:
Здравствуйте, remark, Вы писали:

R>Можно ли трактовать такую фразу как-то ещё, кроме как:

R>Подходит, если не... == не подходит
R>?

Трактовать можно как угодно, только кроме флейма из этого ничего не получится

R>А как, кстати, касательно производительности? Гарантий использования памяти? Возможности контролировать локальность размещения объектов в памяти?

R>Если есть GC — то тоже не подходит, т.к. скорее всего Стэн'у придётся заняться своим кастомным GC.

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

Насчет рантайма, не знаю может и не подойдет, зависит от того насколько низкий уровень ему нужен. Если слишком низкий то си альтернатив практически нет.
Re[26]: C++0x начали урезать
От: remark Россия http://www.1024cores.net/
Дата: 18.12.07 09:56
Оценка:
Здравствуйте, FR, Вы писали:

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


R>>Можно ли трактовать такую фразу как-то ещё, кроме как:

R>>Подходит, если не... == не подходит
R>>?

FR>Трактовать можно как угодно, только кроме флейма из этого ничего не получится



А это разьве раздел не для флейма?


R>>А как, кстати, касательно производительности? Гарантий использования памяти? Возможности контролировать локальность размещения объектов в памяти?

R>>Если есть GC — то тоже не подходит, т.к. скорее всего Стэн'у придётся заняться своим кастомным GC.

FR>Производительность хорошая, чуть шустрее java C# и чуть мендленее C++.

FR>GC есть, говорят один из самых шустрых и нежадных к ресурсам. Оптимизатор очень хорош, почти везде где можно обойтись без GC обходится без него.


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


FR>Насчет рантайма, не знаю может и не подойдет, зависит от того насколько низкий уровень ему нужен. Если слишком низкий то си альтернатив практически нет.



Низкий, не низкий — сложно сказать, вопрос терминологии. Но так скажем — большая часть кода это не традиционный прикладной код, от которого всё, что нужно это лишь функциональность. Вопросы временной сложности, вопросы объёмной сложности, вопросы масштабируемости идут на равне с вопросом голой функциональности. И тут главное, что бы язык/рантайм не ограничивал тебя ни в чём, и не привязывал ни к каким "встроенным" решениям — а это в той или иной мере присуще всем "управляемым" языкам.
По поводу С. В принципе С++ при разумном использовании тоже вполне подходит. Единственное, что иногда разумное — это использование только более строгой типизации, перегрузки функций и ссылок. Но зачастую можно и виртуальными функциями побаловаться



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[27]: C++0x начали урезать
От: FR  
Дата: 18.12.07 10:22
Оценка:
Здравствуйте, remark, Вы писали:


R>А это разьве раздел не для флейма?





R>Тут нужны не традиционные оптимизации, которые нужны в прикладном коде. Например по поводу GC имеется в виду, не то, что если объект создан и используется только локально в функции, то для него можно сделать синхронное удаление без помощи GC. Имеются в виду как раз самые что ни на есть активно разделяемые между разными потоками объекты.

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

Для такого уровня конечно да пролетает.

FR>>Насчет рантайма, не знаю может и не подойдет, зависит от того насколько низкий уровень ему нужен. Если слишком низкий то си альтернатив практически нет.



R>Низкий, не низкий — сложно сказать, вопрос терминологии. Но так скажем — большая часть кода это не традиционный прикладной код, от которого всё, что нужно это лишь функциональность. Вопросы временной сложности, вопросы объёмной сложности, вопросы масштабируемости идут на равне с вопросом голой функциональности. И тут главное, что бы язык/рантайм не ограничивал тебя ни в чём, и не привязывал ни к каким "встроенным" решениям — а это в той или иной мере присуще всем "управляемым" языкам.

R>По поводу С. В принципе С++ при разумном использовании тоже вполне подходит. Единственное, что иногда разумное — это использование только более строгой типизации, перегрузки функций и ссылок. Но зачастую можно и виртуальными функциями побаловаться

C++ конечно подходит, только шаблоны на низком уровне точно полезней чем виртуальный функции
Re[17]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.12.07 16:01
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>Лезть в отладчик для определения типа это мощно. Вот вам и вывод типов (про такие же проблемы в с++ знаю, так что это палка о двух концах).


Не только для этого. В отладчике ты видишь контекст и можешь трассировать исполнение. Это очень хорошо проясняет картину. Иногда от знания типа толку — ноль.

VD>>А вот Рефлектор на Немерле падает.


КЛ>редко, но бывало


Постоянно если тело фунции содержит рекурсию и сложные матчи.

КЛ>Использовать отладчик для борьбы с выводом типов? Мдя...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.12.07 16:01
Оценка:
Здравствуйте, EvilChild, Вы писали:

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


EC>Concepts эту задачу решают. Некий аналог классов типов Хаскеля.


До Хаскелевских классов типов шаблонам С++ никогда не дорости.
Да, и не решают они ничего. Они позволяют прояснить интерфейс параметра типа. Но не зсаставляют использовать их везде. Что создает недетерминизм.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.12.07 16:03
Оценка:
Здравствуйте, remark, Вы писали:

R>Вот, пожалуйста. Меньше, кстати, получается:


R>
R>struct BinIntCall {string name; int a1, a2;};
R>struct BinOp {string name; any a1, a2;};

R>void to_str(any e)
R>{
R>    if (double* d = any_cast(e)) cout << *d;
R>    else if (BinIntCall* c = any_cast(e)) cout << c->name << "(" << c->a1 << "," << c->a2 << ")";
R>    else if (BinOp* c = any_cast(e)) to_str(c->a1); cout << c->name; to_str(c->a2);
R>    else throw 0;
R>}
R>


Что это за бред?

Может поглядишь исходную задачу?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 18.12.07 17:07
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>До Хаскелевских классов типов шаблонам С++ никогда не дорости.

Я этого и не утверждал.

VD>Да, и не решают они ничего. Они позволяют прояснить интерфейс параметра типа. Но не зсаставляют использовать их везде. Что создает недетерминизм.

Мы говорим об одном и том же: консептам из драфта нового стандарта C++?
now playing: Scorn — Stripped Back Hinge
Re[19]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.12.07 11:13
Оценка:
Здравствуйте, EvilChild, Вы писали:

VD>>Да, и не решают они ничего. Они позволяют прояснить интерфейс параметра типа. Но не зсаставляют использовать их везде. Что создает недетерминизм.

EC>Мы говорим об одном и том же: консептам из драфта нового стандарта C++?

Ага. Они не обязательны для применения. Как я пониял ты по рпежнему сможешь писать код без концептов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.12.07 13:51
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Естественно, иначе весь существующий код без концептов перестанет компилироваться.


Ага.

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


Я считаю, что косяки лучше не допускать. Тот же Немерле проектировался с нуля и без компромисов для (скажем) совместимости с С.
С++ можно сделать удобным только если таки отказаться от совместимости. Я бы тупо ввел два режима. 1. Режим совместимости в ктором все по старому. 2. Режим 0х в котором многое запрещено и не допустимо, но зато обеспечивается полноценный контроль. Первое что я бы запретил — это препроцессор. Второе — использование указателей. Третье — программироание шаблонов без концептов.

J>Так что не очень понятно, о чем была твоя реплика.


Теперь понятнее?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: C++0x начали урезать
От: Курилка Россия http://kirya.narod.ru/
Дата: 19.12.07 14:34
Оценка:
Здравствуйте, jazzer, Вы писали:

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


VD>>Тот же Немерле проектировался с нуля и без компромисов для (скажем) совместимости с С.

J>Это он сейчас так проектировался.
J>А вот когда ему стукнет 20 лет, как С++, тогда ему придется обеспечивать прежде всего совместимость с самим собой, если, конечно, он собирается эволюционировать.

Только не стоит забывать, что и 20 лет назад он проектировался исходя из обратной совместимости с C
Re[24]: C++0x начали урезать
От: jazzer Россия Skype: enerjazzer
Дата: 19.12.07 14:38
Оценка:
Здравствуйте, Курилка, Вы писали:

VD>>>Тот же Немерле проектировался с нуля и без компромисов для (скажем) совместимости с С.

J>>Это он сейчас так проектировался.
J>>А вот когда ему стукнет 20 лет, как С++, тогда ему придется обеспечивать прежде всего совместимость с самим собой, если, конечно, он собирается эволюционировать.

К>Только не стоит забывать, что и 20 лет назад он проектировался исходя из обратной совместимости с C

Почему это?

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

И это относится к любому языку.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[23]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.12.07 15:34
Оценка:
Здравствуйте, jazzer, Вы писали:

VD>>Тот же Немерле проектировался с нуля и без компромисов для (скажем) совместимости с С.

J>Это он сейчас так проектировался.
J>А вот когда ему стукнет 20 лет, как С++, тогда ему придется обеспечивать прежде всего совместимость с самим собой, если, конечно, он собирается эволюционировать.

А С++ так проектировался когда он еще даже С++-мо не был, а был СиСсКлассами.

VD>>С++ можно сделать удобным только если таки отказаться от совместимости.

J>Ну мне лично совместимость никак не мешает.

Ну, ты лично этим маральным уродством и пользуешся. А я вот попробовал алтернативу. Теперь обратно не то что бы не тянет, а тошнить начинает просто от прсмотра кода на С++.

VD>>Я бы тупо ввел два режима. 1. Режим совместимости в ктором все по старому. 2. Режим 0х в котором многое запрещено и не допустимо, но зато обеспечивается полноценный контроль. Первое что я бы запретил — это препроцессор. Второе — использование указателей. Третье — программироание шаблонов без концептов.


J>А, ну опций компиляции можно завсегда придумать вагон, с этим никто и не спорит.


Это не опции компиляции, а скорее области видимости (скопы) в которых допустим/недопустим старый/новый синтаксис. Как с опасным кодом в Шарпе.

J>Ты и сейчас можешь, скажем, запускать gcc с максимальным уровнем варнингов и в pedantic mode, в котором он пишет кучу варнингов, и при этом еще одним флажком сказать, что все варнинги — это ошибки — и получишь примерно то же — запрет всех показавшихся компилятору опасными конструкций.


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

Так и вижу:

Warning: You use C++ in C++ 0x! Kill yourself!!!


J>Только это не надо никому, видимо, по крайней мере, я не слышал, чтобы этим (выключением "опасных" фич) кто-то реально пользовался, вот это и не получает особого развития.


Ну, мне вот не надо С++ даже в виде 0х. А ведь когда-то я даже подумать об этом не мог. Так что не надо про "не надо никому".

J>Двумя режимами точно никто не обойдется, потому что выбрасывать весь старый код ради того, чтоб заюзать одну новую фичу, абсолютно бессмысленно. И не юзать фичу ради сохранения старого кода столь же бессмысленно. А посему никто не будет делать подобных "или-или" режимов — ими просто никто не будет пользоваться.


Я не предлагал выбрасывать. Я предлагал четко разделить старый иновый, чтобы можно было порвать с совместимостью в новом языке.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: C++0x начали урезать
От: jazzer Россия Skype: enerjazzer
Дата: 19.12.07 15:46
Оценка:
Здравствуйте, VladD2, Вы писали:

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


E>>Зачем кому-нибудь C++ без препроцессора и указателей?


VD>Я бы упростил бы это вопрос. Например, так:

VD>

Зачем кому-нибудь C++?

VD>или даже:
VD>

Зачем C++?


или даже:

Зачем?


VD>Те же текстуаьные макросы можно заменить немерлоподобными.

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

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

Но при этом другого способа пройтись по встроенному массиву или встроенной строке, кроме адресной арифметики, нету, если не хочется терять скорость, конечно.
Хотя в моем коде подобные вещи обычно упрятаны в классы либо просто используются алгоритмы STL.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[25]: C++0x начали урезать
От: Andrei F.  
Дата: 19.12.07 16:03
Оценка:
Здравствуйте, eao197, Вы писали:

E>Вот через 20 лет кто-нибудь поставит Nemerle в упрек то, что он создавался под .NET.


Помнится, не так давно кое-кто вообще отрицал, что у него будет какое-либо будущее. Да и сейчас еще такие не перевелись
Re[26]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.12.07 16:07
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


E>>Вот через 20 лет кто-нибудь поставит Nemerle в упрек то, что он создавался под .NET.


AF>Помнится, не так давно кое-кто вообще отрицал, что у него будет какое-либо будущее. Да и сейчас еще такие не перевелись


А где фактические доказательства того что они, т.е. мы, были не правы?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[27]: C++0x начали урезать
От: Andrei F.  
Дата: 19.12.07 16:23
Оценка:
Здравствуйте, eao197, Вы писали:

E>>>Вот через 20 лет кто-нибудь поставит Nemerle в упрек то, что он создавался под .NET.


Хрустального шара, чтобы в нем показать, у меня нет. Но сам факт таких высказываний (см выше) уже о многом говорит
Re[25]: C++0x начали урезать
От: jazzer Россия Skype: enerjazzer
Дата: 19.12.07 16:31
Оценка:
Здравствуйте, eao197, Вы писали:

VD>>А если серьезнь, то есть менее кривые средства. Те же текстуаьные макросы можно заменить немерлоподобными.


E>Макросы в топку.

E>Мне препроцессор в C++ нужен для устранения различий между платформами и поддержкой разных режимов компиляции. Ну еще за макросами удобно прятать вещи типа assert или trace, которые из release версии вырезаются напрочь.

E>Использование C-ных макросов для более серьезных вещей, по моему опыту, является следствием непродуманного дизайна. Когда на поиск более подходящей реализации не хватило времени, подходящих инструментов или хорошей идеи.


Видишь ли, программа, как ни крути — это текстовый файл, и есть вещи, которые хочется делать именно на этом уровне (если, конечно, нет доступа к более продвинутым средствам, типа немер левых макросов, которые работают напрямую с синтаксическим деревом — тогда эти же вещи захочется делать на уровне преобразования дерева), и никакими другими способами ты для этих вещей такой же ясности и лаконичности не добьешься.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[24]: C++0x начали урезать
От: jazzer Россия Skype: enerjazzer
Дата: 19.12.07 16:42
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А С++ так проектировался когда он еще даже С++-мо не был, а был СиСсКлассами.


И что? Или мне повторить мой ответ Курилке?

VD>>>С++ можно сделать удобным только если таки отказаться от совместимости.

J>>Ну мне лично совместимость никак не мешает.

VD>Ну, ты лично этим маральным уродством и пользуешся. А я вот попробовал алтернативу.


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

VD>Теперь обратно не то что бы не тянет, а тошнить начинает просто от прсмотра кода на С++.


Ну я даже и не знаю, как это прокомментировать. Разве что как-то вроде: слишком сильные эмоции для человека, который утверждает, что язык для него — лишь инструмент.

VD>Это не опции компиляции, а скорее области видимости (скопы) в которых допустим/недопустим старый/новый синтаксис. Как с опасным кодом в Шарпе.


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


VD>Где-то такой подход прокатит. Где-то нужно большая гранулярность. И опять же важно, чтобы кроме указателей были другие средства сделать ту же работу. Иначе на что варнинги то кидать? На сам язык?


Да понял я уже, о чем ты, понял.

VD>Ну, мне вот не надо С++ даже в виде 0х. А ведь когда-то я даже подумать об этом не мог. Так что не надо про "не надо никому".

Не надо никому из пишущих на С++. Ты, очевидно, к ним не относишься.

J>>Двумя режимами точно никто не обойдется, потому что выбрасывать весь старый код ради того, чтоб заюзать одну новую фичу, абсолютно бессмысленно. И не юзать фичу ради сохранения старого кода столь же бессмысленно. А посему никто не будет делать подобных "или-или" режимов — ими просто никто не будет пользоваться.


VD>Я не предлагал выбрасывать.

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

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


Если это будет соответствующим образом гранулироваться — я только за. И, опять же, совсем не 2 режима (все или ничего), а отдельное управление каждой "опасной" фичей.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[26]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.12.07 16:54
Оценка:
Здравствуйте, jazzer, Вы писали:

E>>Использование C-ных макросов для более серьезных вещей, по моему опыту, является следствием непродуманного дизайна. Когда на поиск более подходящей реализации не хватило времени, подходящих инструментов или хорошей идеи.


J>Видишь ли, программа, как ни крути — это текстовый файл, и есть вещи, которые хочется делать именно на этом уровне (если, конечно, нет доступа к более продвинутым средствам, типа немер левых макросов, которые работают напрямую с синтаксическим деревом — тогда эти же вещи захочется делать на уровне преобразования дерева), и никакими другими способами ты для этих вещей такой же ясности и лаконичности не добьешься.


Внешний DSL и pre-compile-time генерация кода. Чтобы можно было получить результат этой генерации в виде чистого C++ кода. Чтобы затем отладчиком по нему пройтись можно было. А если этот DSL генерирует какие-то классы/функции, чтобы инструменты типа doxygen могли их в отчет включить.

А то потом всякие эксперименты с созданием своего подъязычка на макросах боком вылазят. По разном причинам. Например, сложно обеспечивать совместимость при необходимости расширения подъязыка.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[27]: C++0x начали урезать
От: jazzer Россия Skype: enerjazzer
Дата: 19.12.07 17:26
Оценка:
Здравствуйте, eao197, Вы писали:

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


E>>>Использование C-ных макросов для более серьезных вещей, по моему опыту, является следствием непродуманного дизайна. Когда на поиск более подходящей реализации не хватило времени, подходящих инструментов или хорошей идеи.


J>>Видишь ли, программа, как ни крути — это текстовый файл, и есть вещи, которые хочется делать именно на этом уровне (если, конечно, нет доступа к более продвинутым средствам, типа немер левых макросов, которые работают напрямую с синтаксическим деревом — тогда эти же вещи захочется делать на уровне преобразования дерева), и никакими другими способами ты для этих вещей такой же ясности и лаконичности не добьешься.


E>Внешний DSL и pre-compile-time генерация кода. Чтобы можно было получить результат этой генерации в виде чистого C++ кода. Чтобы затем отладчиком по нему пройтись можно было. А если этот DSL генерирует какие-то классы/функции, чтобы инструменты типа doxygen могли их в отчет включить.


E>А то потом всякие эксперименты с созданием своего подъязычка на макросах боком вылазят. По разном причинам. Например, сложно обеспечивать совместимость при необходимости расширения подъязыка.


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

Ну и неудобно просто, у меня порядком опыта было с такой генерацией, и никогда это удобно не было.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[28]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.12.07 17:33
Оценка:
Здравствуйте, jazzer, Вы писали:

E>>Внешний DSL и pre-compile-time генерация кода. Чтобы можно было получить результат этой генерации в виде чистого C++ кода. Чтобы затем отладчиком по нему пройтись можно было. А если этот DSL генерирует какие-то классы/функции, чтобы инструменты типа doxygen могли их в отчет включить.


E>>А то потом всякие эксперименты с созданием своего подъязычка на макросах боком вылазят. По разном причинам. Например, сложно обеспечивать совместимость при необходимости расширения подъязыка.


J>Оно боком вылазит, если делаешь страшные вещи. А если нужно просто немножко пошаманить — то вполне нормально все работает.

J>Внешние тулы — они, во-первых, внешние, во-вторых, они работают на уровне всего файла, что обычно совсем не надо.

J>Ну и неудобно просто, у меня порядком опыта было с такой генерацией, и никогда это удобно не было.


А ты можешь привести примеры того, о чем говоришь?

А то может получится, что мы вообще о разных вещах разговариваем.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[30]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.12.07 18:03
Оценка:
Здравствуйте, jazzer, Вы писали:

J>ну представь что у тебя есть код на три строчки и его надо размножить десятикратно прям тут же (case-ы в свитче, скажем), причем к функциям это легко не сводится? даже к шаблонным, потому что различия в типах, в строках (литералах) и т.п.

J>Вот такие три строчки упрятать под одну строчку макроса и потом эти 10 строчек написать — милое дело, все ясно и понятно.
J>И надежно, кстати, потому что ты полностью защищен от ошибок копи-пейста — у тебя вместо разноженного трехстрочного блока кода (где черт ногу сломит и не поймешь, правильно ли все употреблено или при копи-пейсте всё поменяли, а вот тут забыли) всего одна строчка вызова макроса и каждая сущность там упоминается ровно один раз.
J>И сразу после этих 10 строчек поставить #undef

Ну и зачем при этом навороченный механизм макросов?

Я на внешних DSL-ях делал более навороченную генерацию
Автор: eao197
Дата: 08.09.05
, для которой C-шных макросов не хватало. В пределе это может дойти до показанного здесь
Автор: eao197
Дата: 16.09.05
примера (с генерацией кода по выборке данных).


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[31]: C++0x начали урезать
От: jazzer Россия Skype: enerjazzer
Дата: 19.12.07 19:04
Оценка:
Здравствуйте, eao197, Вы писали:

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


J>>ну представь что у тебя есть код на три строчки и его надо размножить десятикратно прям тут же (case-ы в свитче, скажем), причем к функциям это легко не сводится? даже к шаблонным, потому что различия в типах, в строках (литералах) и т.п.

J>>Вот такие три строчки упрятать под одну строчку макроса и потом эти 10 строчек написать — милое дело, все ясно и понятно.
J>>И надежно, кстати, потому что ты полностью защищен от ошибок копи-пейста — у тебя вместо разноженного трехстрочного блока кода (где черт ногу сломит и не поймешь, правильно ли все употреблено или при копи-пейсте всё поменяли, а вот тут забыли) всего одна строчка вызова макроса и каждая сущность там упоминается ровно один раз.
J>>И сразу после этих 10 строчек поставить #undef

E>Ну и зачем при этом навороченный механизм макросов?


Погоди, ты ведь начал с общего "Макросы в топку" с расшифровкой "Мне препроцессор в C++ нужен для устранения различий между платформами и поддержкой разных режимов компиляции. Ну еще за макросами удобно прятать вещи типа assert или trace, которые из release версии вырезаются напрочь."

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

E>Я на внешних DSL-ях делал более навороченную генерацию
Автор: eao197
Дата: 08.09.05
, для которой C-шных макросов не хватало. В пределе это может дойти до показанного здесь
Автор: eao197
Дата: 16.09.05
примера (с генерацией кода по выборке данных).


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

Для такого, имхо, лучше встроенный DSL, с поддержкой автокомплитов и прочего.
И что толку мне с того, что doxygen сгенерит документацию для сгенеренных потрохов?

Скажем, зачем мне корячиться и юзать lex/bison/yacc для генерации парсера (и уж тем более зачем мне документация по сгенеренному ими коду), если я могу заюзать Boost.Spirit, который представляет собой вполне валидный С++ и еще с кучей разных вкусностей, которых у внешних тулов нету, и при этом выглядит очень близко к EBNF? Правильно, незачем (в большинстве случаев). И если б мне пришлось для этого юзать макросы — я бы совсем не обиделся.

Или вот scope.exit из твоего любимого D — Саша Насонов реализовал это дело для С++, но с помощью макросов — а попробуй объедь это дело без их помощи — поолезут страшные страшности...
А если бы в С++ были макросы типа немерлевых, позволяющие изменять синтаксис — можно было бы вообще добиться естественного синтаксиса объявления блока.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[32]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.12.07 07:01
Оценка:
Здравствуйте, jazzer, Вы писали:

E>>Ну и зачем при этом навороченный механизм макросов?


J>Погоди, ты ведь начал с общего "Макросы в топку" с расшифровкой "Мне препроцессор в C++ нужен для устранения различий между платформами и поддержкой разных режимов компиляции. Ну еще за макросами удобно прятать вещи типа assert или trace, которые из release версии вырезаются напрочь."


J>То, что я описываю, под твои рамки не подходит, стало быть, в топку


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

E>>Я на внешних DSL-ях делал более навороченную генерацию
Автор: eao197
Дата: 08.09.05
, для которой C-шных макросов не хватало. В пределе это может дойти до показанного здесь
Автор: eao197
Дата: 16.09.05
примера (с генерацией кода по выборке данных).


J>Я тоже делал, и не могу сказать, что был счастлив.


J>Для такого, имхо, лучше встроенный DSL, с поддержкой автокомплитов и прочего.


Которого для C++ никогда не будет. Мы ведь здесь все еще про C++ говорим

J>И что толку мне с того, что doxygen сгенерит документацию для сгенеренных потрохов?


Ну, кстати, Java IDE используют JavaDoc комментарии при выдаче подсказок. Почему бы какому-нибудь KDevelop не делать то же самое с помощью doxygen комментариев? Насколько я помню, даже Visual Studio 6 умела показывать части комментариев при автокомплите. И опять же мы остаемся в рамках старого доброго C++, который уже сейчас поддерживают сотни разных инструментов.

J>Скажем, зачем мне корячиться и юзать lex/bison/yacc для генерации парсера (и уж тем более зачем мне документация по сгенеренному ими коду), если я могу заюзать Boost.Spirit, который представляет собой вполне валидный С++ и еще с кучей разных вкусностей, которых у внешних тулов нету, и при этом выглядит очень близко к EBNF? Правильно, незачем (в большинстве случаев). И если б мне пришлось для этого юзать макросы — я бы совсем не обиделся.


Насколько я помню, lex/bison/yacc достаточно примитивны по сравнению с современными конкурентами типа ANTLR, Ragel и пр. Зачем мне брать монстрообразный Boost.Spirit, если можно взять специальный инструмент, очень хорошо заточенный под свои задачи. Для ANTLR есть достаточное количество примеров, документации и даже какой-то визуальный тул для отладки своих парсеров.

J>Или вот scope.exit из твоего любимого D — Саша Насонов реализовал это дело для С++, но с помощью макросов — а попробуй объедь это дело без их помощи — поолезут страшные страшности...


Вот в этом и проблема, лучше бы не Саша Насонов с помощью макросов, а Страуструп в компиляторе языка. А если это в языке не сделано, то может есть на это причины? Может в scope.exit есть потенциальные проблемы, которые разработчики языка видят, а вот обычные пользователи -- нет.

Тем более, что у scope в D есть три варианта, поддерживает ли их все реализация Насонова?

J>А если бы в С++ были макросы типа немерлевых, позволяющие изменять синтаксис — можно было бы вообще добиться естественного синтаксиса объявления блока.


Ну посмотри на то, что с Lisp-ами произошло. У каждого разработчика свой язык.

Как показывала практика, наиболее успешными и востребованными являлись языки, в которых изменение синтаксиса штатными средствами языка невозможно. Java и C# тому яркие примеры.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[33]: C++0x начали урезать
От: jazzer Россия Skype: enerjazzer
Дата: 20.12.07 08:28
Оценка:
Здравствуйте, eao197, Вы писали:

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


E>>>Ну и зачем при этом навороченный механизм макросов?


J>>Погоди, ты ведь начал с общего "Макросы в топку" с расшифровкой "Мне препроцессор в C++ нужен для устранения различий между платформами и поддержкой разных режимов компиляции. Ну еще за макросами удобно прятать вещи типа assert или trace, которые из release версии вырезаются напрочь."


J>>То, что я описываю, под твои рамки не подходит, стало быть, в топку


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


Внешняя генерация столь же неудобна, по тем же самым причинам.

E>>>Я на внешних DSL-ях делал более навороченную генерацию
Автор: eao197
Дата: 08.09.05
, для которой C-шных макросов не хватало. В пределе это может дойти до показанного здесь
Автор: eao197
Дата: 16.09.05
примера (с генерацией кода по выборке данных).


J>>Я тоже делал, и не могу сказать, что был счастлив.


J>>Для такого, имхо, лучше встроенный DSL, с поддержкой автокомплитов и прочего.


E>Которого для C++ никогда не будет. Мы ведь здесь все еще про C++ говорим


Вот тебе пример — Boost.Spirit. Или Boost.Python. Или Boost.Expressive.

J>>И что толку мне с того, что doxygen сгенерит документацию для сгенеренных потрохов?


E>Ну, кстати, Java IDE используют JavaDoc комментарии при выдаче подсказок. Почему бы какому-нибудь KDevelop не делать то же самое с помощью doxygen комментариев? Насколько я помню, даже Visual Studio 6 умела показывать части комментариев при автокомплите. И опять же мы остаемся в рамках старого доброго C++, который уже сейчас поддерживают сотни разных инструментов.


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

J>>Скажем, зачем мне корячиться и юзать lex/bison/yacc для генерации парсера (и уж тем более зачем мне документация по сгенеренному ими коду), если я могу заюзать Boost.Spirit, который представляет собой вполне валидный С++ и еще с кучей разных вкусностей, которых у внешних тулов нету, и при этом выглядит очень близко к EBNF? Правильно, незачем (в большинстве случаев). И если б мне пришлось для этого юзать макросы — я бы совсем не обиделся.


E>Насколько я помню, lex/bison/yacc достаточно примитивны по сравнению с современными конкурентами типа ANTLR, Ragel и пр. Зачем мне брать монстрообразный Boost.Spirit, если можно взять специальный инструмент, очень хорошо заточенный под свои задачи. Для ANTLR есть достаточное количество примеров, документации и даже какой-то визуальный тул для отладки своих парсеров.


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

J>>Или вот scope.exit из твоего любимого D — Саша Насонов реализовал это дело для С++, но с помощью макросов — а попробуй объедь это дело без их помощи — поолезут страшные страшности...


E>Вот в этом и проблема, лучше бы не Саша Насонов с помощью макросов, а Страуструп в компиляторе языка. А если это в языке не сделано, то может есть на это причины? Может в scope.exit есть потенциальные проблемы, которые разработчики языка видят, а вот обычные пользователи -- нет.

Не лучше. И проблема не в этом.
Одна из причин — на все фичи не напасешься времени. Мало ли какую фичу изобретут в следующем году в очередном языке, и она будет признана полезной и в С++? И что, на каждый чих менять язык?
Язык должен позволять подобные фичи, в которых возникла необходимость прямо сейчас, реализовывать прямо сейчас, и чтоб они выходили более-менее читабельными.
Для этой цели у нас есть макросы как средство генерации кода внутри самого языка, если нельзя сгенерировать этот код другими средствами (шаблонами, скажем).

E>Тем более, что у scope в D есть три варианта, поддерживает ли их все реализация Насонова?

Нет, ее невозможно в С++ сделать в принципе (в текущей редакции). Только scope_exit.

J>>А если бы в С++ были макросы типа немерлевых, позволяющие изменять синтаксис — можно было бы вообще добиться естественного синтаксиса объявления блока.


E>Ну посмотри на то, что с Lisp-ами произошло. У каждого разработчика свой язык.


E>Как показывала практика, наиболее успешными и востребованными являлись языки, в которых изменение синтаксиса штатными средствами языка невозможно. Java и C# тому яркие примеры.


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

E>Я вообще негативно отношусь к предоставлению разработчикам возможности создавать свои подъязыки и изменять синтаксис основного языка -- слишком это сложно, сделать хороший язык. За всю историю программирования это удавалось очень не многим.


В широком смысле, ты эти языки создаешь ежечасно.
Написал два взаимодействующих класса — вот тебе и мини-язык, сразу.
Все многочисленные классы и функции, которые ты пишешь, служат тому, чтобы решение задачи в результате записывалось несколькими понятными с первого взгляда строчками, которые уже зовут внутри себя все свои потроха.
А это и означает, что ты для этой своей задачи только что создал свой мини-язык.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[33]: C++0x начали урезать
От: FR  
Дата: 20.12.07 08:36
Оценка:
Здравствуйте, eao197, Вы писали:

E>Я вообще негативно отношусь к предоставлению разработчикам возможности создавать свои подъязыки и изменять синтаксис основного языка -- слишком это сложно, сделать хороший язык. За всю историю программирования это удавалось очень не многим.


По моему в этом нет ничего плохого, если гибкость не чрезмерна, или требует дополнительных усилий типа как AST препроцессор в Ocaml или питоновский http://www.fiber-space.de/EasyExtend/doc/EE.html (они неплохо прикололись реализовав с его помощью Python 2.5 на Python 2.4 http://www.fiber-space.de/EasyExtend/doc/Py25Lite/Py25Lite.html ).

Хотя путь Lisp, Forth, Mozart-Oz, Nemerle тоже вполне хорош для небольшой команды или одиночного разработчика.
Re[34]: C++0x начали урезать
От: Константин Л. Франция  
Дата: 20.12.07 09:23
Оценка:
Здравствуйте, jazzer, Вы писали:

[]

В общем, согласен.

E>>Я вообще негативно отношусь к предоставлению разработчикам возможности создавать свои подъязыки и изменять синтаксис основного языка -- слишком это сложно, сделать хороший язык. За всю историю программирования это удавалось очень не многим.


J>В широком смысле, ты эти языки создаешь ежечасно.

J>Написал два взаимодействующих класса — вот тебе и мини-язык, сразу.
J>Все многочисленные классы и функции, которые ты пишешь, служат тому, чтобы решение задачи в результате записывалось несколькими понятными с первого взгляда строчками, которые уже зовут внутри себя все свои потроха.
J>А это и означает, что ты для этой своей задачи только что создал свой мини-язык.

Не совсем. Семантика разная, а вот синтаксис одинаковый. eao197 говорит про различные синтаксисы, порожденные макросами.
Re[34]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.12.07 10:09
Оценка:
Здравствуйте, jazzer, Вы писали:

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


J>Внешняя генерация столь же неудобна, по тем же самым причинам.


Не соглашусь, т.к. это противоречит тому, с чем мне приходилось сталкиваться. Например, у меня в SObjectizer много описаний делается C-ными макросами (кстати, один из корней нелюбви к макросам). И когда временами приходится посмотреть, что происходит во вспомогательном коде перед вызовом обработчика события, то приходится править исходник макроса. Соответственно, модифицируются все участки кода, порожденные этим макросом. И, если модификацию макроса сделать неаккуратно, то вместо одной отладочной печати получишь в буквальном смысле миллион.

С другой стороны, я использую систему сериализации, в которой по внешнему описанию в виде DDL-файла строится простыня вспомогательного кода для каждого сериализуемого класса. И результирующий C++ный код для конкретного класса или атрибута я могу подправить.

E>>>>Я на внешних DSL-ях делал более навороченную генерацию
Автор: eao197
Дата: 08.09.05
, для которой C-шных макросов не хватало. В пределе это может дойти до показанного здесь
Автор: eao197
Дата: 16.09.05
примера (с генерацией кода по выборке данных).


J>>>Я тоже делал, и не могу сказать, что был счастлив.


J>>>Для такого, имхо, лучше встроенный DSL, с поддержкой автокомплитов и прочего.


E>>Которого для C++ никогда не будет. Мы ведь здесь все еще про C++ говорим


J>Вот тебе пример — Boost.Spirit. Или Boost.Python. Или Boost.Expressive.


А вот интересно, когда ты используешь Boost.Expressive тебе подсказка выдается по public-интерфейсам Boost.Expressive или по синтаксису регулярных выражений?

J>>>И что толку мне с того, что doxygen сгенерит документацию для сгенеренных потрохов?


E>>Ну, кстати, Java IDE используют JavaDoc комментарии при выдаче подсказок. Почему бы какому-нибудь KDevelop не делать то же самое с помощью doxygen комментариев? Насколько я помню, даже Visual Studio 6 умела показывать части комментариев при автокомплите. И опять же мы остаемся в рамках старого доброго C++, который уже сейчас поддерживают сотни разных инструментов.


J>не, ты не понял, я имею в виду, что мне нужна документация на одну единственную строчку, где вызван макрос, а не документация по километрам сгенеренных потрохов.


Так это от use case зависит. Если я использую инструмент, который мне по XSD/DTD или ASN.1 описанию строит набор C++ классов, то естественно, что я хотел бы видеть документацию по сгенерированным классам.

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

J>>>Скажем, зачем мне корячиться и юзать lex/bison/yacc для генерации парсера (и уж тем более зачем мне документация по сгенеренному ими коду), если я могу заюзать Boost.Spirit, который представляет собой вполне валидный С++ и еще с кучей разных вкусностей, которых у внешних тулов нету, и при этом выглядит очень близко к EBNF? Правильно, незачем (в большинстве случаев). И если б мне пришлось для этого юзать макросы — я бы совсем не обиделся.


E>>Насколько я помню, lex/bison/yacc достаточно примитивны по сравнению с современными конкурентами типа ANTLR, Ragel и пр. Зачем мне брать монстрообразный Boost.Spirit, если можно взять специальный инструмент, очень хорошо заточенный под свои задачи. Для ANTLR есть достаточное количество примеров, документации и даже какой-то визуальный тул для отладки своих парсеров.


J>Сорри, а чем тебе спирит не заточен под эти же самые задачи? С дополнительным плюсом интегрированности в язык, т..е ты можешь использовать все остальные механизмы С++ для работы с ним.


А Spirit -- он LR(1), LALR(1) или LR(*) парсер?
Все может упереться в выразительные возможности языка описания граматики, наличия готовых средств для получения AST, удобства поддержки стека токенов во время парсинга, внятности и точности сообщений о синтаксических ошибках, да и элементарной скорости выполнения парсинга, наконец. Так что интегрированность инструмента в язык -- это может быть еще и недостаток, так как он влияет на остальные критерии оценки.

J>>>Или вот scope.exit из твоего любимого D — Саша Насонов реализовал это дело для С++, но с помощью макросов — а попробуй объедь это дело без их помощи — поолезут страшные страшности...


E>>Вот в этом и проблема, лучше бы не Саша Насонов с помощью макросов, а Страуструп в компиляторе языка. А если это в языке не сделано, то может есть на это причины? Может в scope.exit есть потенциальные проблемы, которые разработчики языка видят, а вот обычные пользователи -- нет.

J>Не лучше. И проблема не в этом.
J>Одна из причин — на все фичи не напасешься времени. Мало ли какую фичу изобретут в следующем году в очередном языке, и она будет признана полезной и в С++? И что, на каждый чих менять язык?

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

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

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


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

J>>>А если бы в С++ были макросы типа немерлевых, позволяющие изменять синтаксис — можно было бы вообще добиться естественного синтаксиса объявления блока.


E>>Ну посмотри на то, что с Lisp-ами произошло. У каждого разработчика свой язык.


E>>Как показывала практика, наиболее успешными и востребованными являлись языки, в которых изменение синтаксиса штатными средствами языка невозможно. Java и C# тому яркие примеры.


J>Ты еще оберон вспомни, в нем еще и оверхеда нету


Оберон обязан дурной славе незабвенному Сергею Губанову. Который с благими намерениями обосрал весьма приличный язык. Он минималистичен и прост, обучить ему нового человека можно без проблем. И за счет своей простоты в нем мало граблей. Конечно же, примитивность Оберона вряд ли позволит использовать его для решения сложных задач, однако для некоторых областей, где предсказуемость и прозрачность кода очень важна, Оберон не самый плохой выбор. Особенно если сравнивать с C. Не зря же Оберон до сих пор во встраиваемых системах для авиации используется. Так что Оберон как раз является примером удачно спроектированного минималистичного языка.

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

J>Ты всерьез считаешь, что успех жавы и шарпа в том, что нельзя изменить синтаксис, а не в том, что их версии пекутся со скоростью 3 новые версии на одну новую версию С++ и в прочих организационных преимуществах?


Я считаю, что эти организационные преимущества не в последнюю очередь обязаны тому, что язык не позволяет любому программисту создавать собственные поддиалекты. Или страшилки, вроде Boost.Spirit-а (не обижайся, но вот не могу понять, какая польза от реализации персера на C++ных шаблонах).

E>>Я вообще негативно отношусь к предоставлению разработчикам возможности создавать свои подъязыки и изменять синтаксис основного языка -- слишком это сложно, сделать хороший язык. За всю историю программирования это удавалось очень не многим.


J>В широком смысле, ты эти языки создаешь ежечасно.

J>Написал два взаимодействующих класса — вот тебе и мини-язык, сразу.
J>Все многочисленные классы и функции, которые ты пишешь, служат тому, чтобы решение задачи в результате записывалось несколькими понятными с первого взгляда строчками, которые уже зовут внутри себя все свои потроха.
J>А это и означает, что ты для этой своей задачи только что создал свой мини-язык.

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

При расширении языка (при изменении синтаксиса) эта стройность теряется. За несколькими строчками уже стоят не только объекты и методы, там уже появляются модификации AST, какие-то действия, которые скрыты от разработчика, и только где-то в конце все это преобразуется в тот же самый набор объектов и методов.

А если к C++ с его мультипарадигменностью метапрограммированием на шаблонах еще и Nemerle-вую макросистему добавить -- все, кранты. Будет MegaMacroBoost, в деталях реализации которого вообще мало кто сможет разобраться


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[35]: C++0x начали урезать
От: jazzer Россия Skype: enerjazzer
Дата: 20.12.07 12:36
Оценка:
Здравствуйте, eao197, Вы писали:

E>С другой стороны, я использую систему сериализации, в которой по внешнему описанию в виде DDL-файла строится простыня вспомогательного кода для каждого сериализуемого класса. И результирующий C++ный код для конкретного класса или атрибута я могу подправить.


А, так ты потом правишь сгенеренный код... Я тебя не понял сначала.
Ну так я в таких случаях делаю то же самое — прогоняю через препроцессор (g++ -E), беру соответствующий кусок кода и вставляю на место вызова макроса (ну и комментирую сам вызов, понятное дело), а дальше — по твоему сценарию.
Заодно я защищен от перекомпиляций/перегенераций, в отличие от тебя, когда при перегенерации все твои изменения улетят.

J>>Вот тебе пример — Boost.Spirit. Или Boost.Python. Или Boost.Expressive.


E>А вот интересно, когда ты используешь Boost.Expressive тебе подсказка выдается по public-интерфейсам Boost.Expressive или по синтаксису регулярных выражений?


Причем тут подсказка? Все эти библиотеки предоставляют встроенный DSL, причем в строгом соответствии с синтаксисом С++, за который ты так ратуешь, хотя он и не очень тут удобен оказывается.


E>Так это от use case зависит. Если я использую инструмент, который мне по XSD/DTD или ASN.1 описанию строит набор C++ классов, то естественно, что я хотел бы видеть документацию по сгенерированным классам.


Тут согласен.

J>>Сорри, а чем тебе спирит не заточен под эти же самые задачи? С дополнительным плюсом интегрированности в язык, т..е ты можешь использовать все остальные механизмы С++ для работы с ним.


E>А Spirit -- он LR(1), LALR(1) или LR(*) парсер?

E>Все может упереться в выразительные возможности языка описания граматики, наличия готовых средств для получения AST, удобства поддержки стека токенов во время парсинга, внятности и точности сообщений о синтаксических ошибках, да и элементарной скорости выполнения парсинга, наконец.
Всегда и везде можно упереться в одно или в другое. У Спирита есть режим отладки, когда он все распечатывает, что спарсилось, можно ходить по распарсенным деревьям и т.д.
А самое главное — это скорость и легкость, с которой пишется парсер и сопутствующие парсингу действия (грубо говоря: "если распарсили число — положи его вот в эту переменную, а потом позови вот эту функцию").
Я очень сомневаюсь, что можно легко разобраться в коде, который генерит внешний тул типа ANTLR, особенно когда задачи разобраться с его потрохами не стоит, а стоит задача распарсить и сделать что-нть в соответствии с распарсенным.

E>Так что интегрированность инструмента в язык -- это может быть еще и недостаток, так как он влияет на остальные критерии оценки.

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

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

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

E>А обратный пример -- любимый мной когда-то язык D. Куда автор пихает все, что ему в голову взбредает. В итоге -- отсутствие стабильного языка в течении 7-ми лет.

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

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


E>Вот это как раз прямой путь к помойке. Не может любая кухарка управлять государством.

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

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

E>Так же язык должен разрабатывать кто-то один или одна команда. А когда каждый будет добавлять собственные варианты foreach-ей, ничего хорошего из этого не выйдет.

См. выше и еще выше (про язык и про обезьян с гранатами).
Кстати, вот foreach — вещь, безусловно, всем нужная, а в языке ее нету, есть супермощная, но не особо удобная и безопасная std::for_each.

J>>>>А если бы в С++ были макросы типа немерлевых, позволяющие изменять синтаксис — можно было бы вообще добиться естественного синтаксиса объявления блока.


E>>>Ну посмотри на то, что с Lisp-ами произошло. У каждого разработчика свой язык.

Лисп — это 1) академический язык и 2) очень неудобный при использовании только базового синтаксиса. Естественно, что его диалектов расплодилось страшное количество.

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

E>>>Как показывала практика, наиболее успешными и востребованными являлись языки, в которых изменение синтаксиса штатными средствами языка невозможно. Java и C# тому яркие примеры.


J>>Ты еще оберон вспомни, в нем еще и оверхеда нету


E>Так что Оберон как раз является примером удачно спроектированного минималистичного языка.

На котором удобно решать только минималистичные задачи.
Ты за такой язык и ратуешь?

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

В смысле — заглянуть? А как же "интеллектуальная собственность"?

J>>Ты всерьез считаешь, что успех жавы и шарпа в том, что нельзя изменить синтаксис, а не в том, что их версии пекутся со скоростью 3 новые версии на одну новую версию С++ и в прочих организационных преимуществах?


E>Я считаю, что эти организационные преимущества не в последнюю очередь обязаны тому, что язык не позволяет любому программисту создавать собственные поддиалекты. Или страшилки, вроде Boost.Spirit-а (не обижайся, но вот не могу понять, какая польза от реализации персера на C++ных шаблонах).


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

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

E>Так вот мне и нравится, что существует всего один слой сущностей в программе -- классы/объекты и методы. Все программа на любом уровне абракции записывается только в этих терминах.


Это она только на уровне текста так записывается.
А реально при программировании ты, помимо объектов/методов, должен держать в голове кучу разной информации о том, как они все совокупляются, в каком порядке что можно звать, как оно аукнется и где откликнется, и т.д. и т.п.
И вот когда подобные вещи удается упрятать в (мини-)язык — это реальная победа.
За примером далеко ходить не надо — подумай на тему const и необходимости его в языке.

E>При расширении языка (при изменении синтаксиса) эта стройность теряется. За несколькими строчками уже стоят не только объекты и методы, там уже появляются модификации AST, какие-то действия, которые скрыты от разработчика, и только где-то в конце все это преобразуется в тот же самый набор объектов и методов.


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

E>А если к C++ с его мультипарадигменностью метапрограммированием на шаблонах еще и Nemerle-вую макросистему добавить -- все, кранты. Будет MegaMacroBoost, в деталях реализации которого вообще мало кто сможет разобраться


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

З.Ы. Если будешь отвечать на это сообщение еще более длинным — отвечай в несколько приемов, хорошо? А то я думал, не закончу это сегодня
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[36]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.12.07 13:12
Оценка:
Здравствуйте, jazzer, Вы писали:

E>>С другой стороны, я использую систему сериализации, в которой по внешнему описанию в виде DDL-файла строится простыня вспомогательного кода для каждого сериализуемого класса. И результирующий C++ный код для конкретного класса или атрибута я могу подправить.


J>А, так ты потом правишь сгенеренный код... Я тебя не понял сначала.

J>Ну так я в таких случаях делаю то же самое — прогоняю через препроцессор (g++ -E), беру соответствующий кусок кода и вставляю на место вызова макроса (ну и комментирую сам вызов, понятное дело), а дальше — по твоему сценарию.

Вспоминаю эти трюки как страшный сон -- когда-то давно я пытался таким образом разобраться в каких-то деталях windows.h

J>Заодно я защищен от перекомпиляций/перегенераций, в отличие от тебя, когда при перегенерации все твои изменения улетят.


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

J>>>Вот тебе пример — Boost.Spirit. Или Boost.Python. Или Boost.Expressive.


E>>А вот интересно, когда ты используешь Boost.Expressive тебе подсказка выдается по public-интерфейсам Boost.Expressive или по синтаксису регулярных выражений?


J>Причем тут подсказка? Все эти библиотеки предоставляют встроенный DSL, причем в строгом соответствии с синтаксисом С++, за который ты так ратуешь, хотя он и не очень тут удобен оказывается.


Ну просто если уж заводить речь о подсказках, то хорошо бы было их получать по предметной области. Пишешь регулярное выражение -- получаешь подсказки по регулярному выражению. Ну или хотя бы подсветку синтаксиса. Вот, например, что я вижу в ViM-е при редактировании Ruby кода:

ViM знает, что внутри строк с двойными кавычками (которые другим цветом выделяются) можно вставлять фрагменты Ruby кода в специальных скобках: #{}. Поэтому ViM умеет выделять этот фрагмент из строки. Более того, глобальные переменные, начинающиеся с $ в ViM помечаются другим цветом и это так же отображается внутри строки.

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

E>>А Spirit -- он LR(1), LALR(1) или LR(*) парсер?

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

А ты можешь сравнить легкость и скорость разработки парсеров, например, при помощи Coco/R, ANTLR или Ragel и Boost.Spirit? Ведь дело в том, что они уже давно далеко ушли вперед по сравнению с lex/yacc. И вызов методов/сохранение результатов там так же делается тривиально.

J>Я очень сомневаюсь, что можно легко разобраться в коде, который генерит внешний тул типа ANTLR, особенно когда задачи разобраться с его потрохами не стоит, а стоит задача распарсить и сделать что-нть в соответствии с распарсенным.


Я больше чем уверен, что разобраться в коде, сгенерированном Ragel или ANTLR вообще удасться, т.к. там используются специальные алгоритмы для генерации оптимального кода для парсинга конкретной граматики. Т.е. генерируется специфический конечный автомат. Посмотри, например, на стартовой страничке Ragel-я пример того, что он строит.

J>Опять же, тот факт, что синтаксис спирита близок к EBNF настолько, насколько это возможно, оставаясь в рамках грамматики С++, то миграция на внешний тул не составит труда.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[36]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.12.07 15:26
Оценка:
Здравствуйте, jazzer, Вы писали:

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

J>Не могу согласиться. Язык — это не набор готовых и всем необходимых решений, а средство для создания этого набора.

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

J>И чем больше язык позволят, не усложняя при этом простые вещи — тем лучше.


Тут не однозначно. Должна выдерживаться какая-то разумная мера сложности.

E>>А обратный пример -- любимый мной когда-то язык D. Куда автор пихает все, что ему в голову взбредает. В итоге -- отсутствие стабильного языка в течении 7-ми лет.

J>Вот именно. А если бы в языке были достаточно гибкие концепции — все эти вещи, котоыре он пихает, уехали бы в стандартную библиотеку.

Вот сильно сомневаюсь, что такие вещи, как константность, замыкания, lazy-аргументы, scope-классы и scope.exit, design by contract могли бы уехать в стандартную библиотеку.

E>>Так что Оберон как раз является примером удачно спроектированного минималистичного языка.

J>На котором удобно решать только минималистичные задачи.
J>Ты за такой язык и ратуешь?

Минималистичность и сложность, и ответственность проекта -- это скорее ортогональные понятия. Если я делаю встроенный софт для радиолокационной станции, то там всего-то может быть 30K строк кода. Но зато уровень требований к качеству и надежности этих 30K строк может быть гораздо выше, чем у, например, SMPP-шлюза в 150K строк кода.

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

J>А во-вторых, страшилки вроде буста являются страшилками не их любви к искусству, а именно потому, что язык не позволяет реализовать нужную функциональность просто. Если бы позволял — никто бы ни в жисть не парился с трехэтажными шаблонами.


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

По мне так: либо какая-то штука работает хорошо, она проста и понятна, либо не нужно делать суррогаты. В этом плане автор D поступает разумно -- нужны лямбды -- пожалуйста, вот вам делегаты и lazy аргументы, а сейчас еще и замыкания сделали. Нужно метапрограммирование -- вот вам static if, is и std.traits. Как раз хороший пример того, как нужные и восстребованные вещи в язык добавляются.

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

E>>Так вот мне и нравится, что существует всего один слой сущностей в программе -- классы/объекты и методы. Все программа на любом уровне абракции записывается только в этих терминах.


J>Это она только на уровне текста так записывается.

J>А реально при программировании ты, помимо объектов/методов, должен держать в голове кучу разной информации о том, как они все совокупляются, в каком порядке что можно звать, как оно аукнется и где откликнется, и т.д. и т.п.
J>И вот когда подобные вещи удается упрятать в (мини-)язык — это реальная победа.
J>За примером далеко ходить не надо — подумай на тему const и необходимости его в языке.

Вот здесь не понял. Вот, допустим, в языке нет const. Кто-то захотел его сделать с помощью макросистемы. Как это возможно?

E>>При расширении языка (при изменении синтаксиса) эта стройность теряется. За несколькими строчками уже стоят не только объекты и методы, там уже появляются модификации AST, какие-то действия, которые скрыты от разработчика, и только где-то в конце все это преобразуется в тот же самый набор объектов и методов.


J>и это правильно, потому что позволяет кратко и понятно выражать более высокоуровневые концепции, которые иначе потерялись бы за лесом объектов и методов.


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

E>>А если к C++ с его мультипарадигменностью метапрограммированием на шаблонах еще и Nemerle-вую макросистему добавить -- все, кранты. Будет MegaMacroBoost, в деталях реализации которого вообще мало кто сможет разобраться


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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[25]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.07 15:57
Оценка:
Здравствуйте, eao197, Вы писали:

VD>>

Зачем C++?


VD>>


E>За него платят.


А я раньше думал, что платят за работу.

VD>>А если серьезнь, то есть менее кривые средства. Те же текстуаьные макросы можно заменить немерлоподобными.


E>Макросы в топку.


С++ без макросов? Гы-гы.

E>Мне препроцессор в C++ нужен для устранения различий между платформами и поддержкой разных режимов компиляции.


А кто о препроцессоре то говорит?

Похоже ты просто не очень представляешь себе что значит "полноценные макросы".

E> Ну еще за макросами удобно прятать вещи типа assert или trace, которые из release версии вырезаются напрочь.


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

E>Использование C-ных макросов для более серьезных вещей, по моему опыту, является следствием непродуманного дизайна. Когда на поиск более подходящей реализации не хватило времени, подходящих инструментов или хорошей идеи.


Дык каково средство, таков и результат. Но, как говорится, за неимением молодой горничной имеем старого дворника.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.07 15:57
Оценка:
Здравствуйте, eao197, Вы писали:

E>Внешний DSL и pre-compile-time генерация кода. Чтобы можно было получить результат этой генерации в виде чистого C++ кода.


Ну, и в чем тут логика? Не лучше ли получить интегрированное решение в котором можно было как отлаживать генерируемый код, так и производить отладку на более высоком урочне — уровне этого самого ДСЛ-я?

E> Чтобы затем отладчиком по нему пройтись можно было.


Дык, и так можно сделать, так чтобы по генерируемому коду можно было отладчиком ходить.
А вот у внешних ДСЛ-ей крайне ограничены области применения, так как они не могут взаимодействовать с основным языком, да и других проблем хватает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.12.07 16:04
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А вот у внешних ДСЛ-ей крайне ограничены области применения, так как они не могут взаимодействовать с основным языком, да и других проблем хватает.


Тоже самое можно сказать и про встроенные DSL-и.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[37]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.07 16:15
Оценка:
Здравствуйте, eao197, Вы писали:

E>Так вот когда мы говорим о встраивании DSL-ей внутрь языка, то хотелось бы, чтобы любой инструмент, который расчитан на этот язык, мог правильно и осмысленно понимать наши DSL-и. И если DSL представляет средства для работы с регулярными выражениями, то хотя бы подсвечивать эти выражения соответствующим образом.


+100

E>А ты можешь сравнить легкость и скорость разработки парсеров, например, при помощи Coco/R, ANTLR или Ragel и Boost.Spirit? Ведь дело в том, что они уже давно далеко ушли вперед по сравнению с lex/yacc. И вызов методов/сохранение результатов там так же делается тривиально.


Boost.Spirit не самый плохой генератор парсеров. Его проблемы в основном заключается в том, что оне не предоставляет полноценной диагностики ошибок в грамматике. Но это из-за того, что он реализован средствами шаблонного метапрограммирвоания, которое, как ты наверно знаешь, не является штатным средством языка, а потому сопряжено с кучей ограничений и проблем. То же решение на Немерле было бы вполне конкурентноспособным с АНТЛР-ом и даже было бы более удобным, так как мы получили бы более тесную интеграцию с языком на котором производится семантический анализ (надеюсь ты знашь, что генераторы парсеров его не автоматизирвют?).

E>Я больше чем уверен, что разобраться в коде, сгенерированном Ragel или ANTLR вообще удасться, т.к. там используются специальные алгоритмы для генерации оптимального кода для парсинга конкретной граматики. Т.е. генерируется специфический конечный автомат. Посмотри, например, на стартовой страничке Ragel-я пример того, что он строит.


АНТЛР генерирует рекурсивный парсер с откатами на исключениях.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.07 16:21
Оценка:
Здравствуйте, eao197, Вы писали:

E>Тоже самое можно сказать и про встроенные DSL-и.


Нет. Все что умеют внешние ДСЛ-и делается встроенными. По сути встроенный ДСЛ всгда можно осформить как отдельную сущьность.

Как пример можно взять те же генераторы парсеров. Их можно делать как встроенным ДСЛ-ем, так и внешним. Тот же Спирит пример построителя парсера реализованного в виде встроенного ДСЛ-я, а АНТЛР — внешнего.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.12.07 16:23
Оценка:
Здравствуйте, VladD2, Вы писали:

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


E>>Тоже самое можно сказать и про встроенные DSL-и.


VD>Нет. Все что умеют внешние ДСЛ-и делается встроенными. По сути встроенный ДСЛ всгда можно осформить как отдельную сущьность.


Уметь-то они могут многое, только что-то может быть нафиг не нужно.
Например, зачем иметь DTD в виде встроенного DSL?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[31]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.07 16:27
Оценка:
Здравствуйте, eao197, Вы писали:

E>Уметь-то они могут многое, только что-то может быть нафиг не нужно.

E>Например, зачем иметь DTD в виде встроенного DSL?

Не нужно, так не нужно. А вот когда нужно будет, то хотелось бы иметь средства (прямые, ане как метапрограммирование на шаблонах) для реализации задуманного.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: C++0x начали урезать
От: FR  
Дата: 20.12.07 17:27
Оценка:
Здравствуйте, eao197, Вы писали:

E>Тут не понял. Язык -- это набор неких концепций, неких кирпичиков. Чем логичнее и целостнее этот набор, тем лучше. На основе этих кирпичиков нужно создавать прикладные решения. А если язык предлагает достраивать сам себя, то вот это мне и не нравится. Язык должны достраивать разработчики языка, а не пользователи.


Почитай Thinking FORTH
Re[22]: C++0x начали урезать
От: deniok Россия  
Дата: 20.12.07 17:48
Оценка:
Здравствуйте, Стэн, Вы писали:

C--?
Re[23]: C++0x начали урезать
От: Стэн http://stanonwork.blogspot.com/
Дата: 20.12.07 18:00
Оценка:
Здравствуйте, deniok, Вы писали:

D>Здравствуйте, Стэн, Вы писали:


D>C--?

Да, спасибо, мне уже подкидывали эту ссылку... Я посмотрел, но вот что я не особо понимаю. Если писать некий код руками, то в качестве высокоуровневого ассемблера (как С) его не очень удобно использовать?! И ли лучше?
А вот если у меня есть какой-то высокоуровневый язык, заточенный под мои задачи, то я могу написать свой компилятор, а могу транслировать свой код в код C--, а потом его откомпилировать. Это его основная задача?
Re[24]: C++0x начали урезать
От: deniok Россия  
Дата: 20.12.07 18:54
Оценка:
Здравствуйте, Стэн, Вы писали:

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


D>>Здравствуйте, Стэн, Вы писали:


D>>C--?

С>Да, спасибо, мне уже подкидывали эту ссылку... Я посмотрел, но вот что я не особо понимаю. Если писать некий код руками, то в качестве высокоуровневого ассемблера (как С) его не очень удобно использовать?! И ли лучше?

Здесь вопрос — какой код писать руками? Если реализовывать низкоуровневые вещи, то, вроде, поудобнее (как я понял он больше гарантий дает чем C по поводу стековых фреймов, допускает jump, разные calling conversion, и т.п.). То есть свой GC реализовать легче, ну и свои механизмы exception handling, concurrency, profiling и debugging тоже, говорят, поудобнее делать. Но я сам только проглядывал статьи, не более.

С>А вот если у меня есть какой-то высокоуровневый язык, заточенный под мои задачи, то я могу написать свой компилятор, а могу транслировать свой код в код C--, а потом его откомпилировать. Это его основная задача?


Вобщем да.
Re[37]: C++0x начали урезать
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.12.07 20:31
Оценка:
Здравствуйте, eao197, Вы писали:

E>Я больше чем уверен, что разобраться в коде, сгенерированном Ragel или ANTLR вообще удасться, т.к. там используются специальные алгоритмы для генерации оптимального кода для парсинга конкретной граматики. Т.е. генерируется специфический конечный автомат.


antlr для паресера никаких автоматов не генерит, там банальный рекурсивный спуск. Ну разобраться в этом коде просто.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[38]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.12.07 13:36
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>antlr для паресера никаких автоматов не генерит, там банальный рекурсивный спуск. Ну разобраться в этом коде просто.


Потому и просто. Правда вроде как 3.0 хотели на автомат перевести. Вот там будет задница.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: C++0x начали урезать
От: CreatorCray  
Дата: 02.01.08 12:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я бы тупо ввел два режима.

VD>2. Режим 0х в котором многое запрещено и не допустимо, но зато обеспечивается полноценный контроль. Первое что я бы запретил — это препроцессор. Второе — использование указателей. Третье — программироание шаблонов без концептов.
С такими ограничениями этот второй режим тогда нафиг никому не нужен. Это уже не C++.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[18]: C++0x начали урезать
От: Programador  
Дата: 04.01.08 22:39
Оценка:
Здравствуйте, minorlogic, Вы писали:

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


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


EC>>Concepts эту задачу решают. Некий аналог классов типов Хаскеля.


M>К сожалению в плюсах шаблоны изначально криво встроенны , и Concepts эти слабая попытка лечения. А вылечить концептальные проблемы скорее всего не получится.


шаблоны придуманы Страуструпом для простых вещей типа vector<>

  int f(char);
  void f(...);
  
  int g=sizeof(f(g));

Противоестественные конструкции появились поздже, а шаблоны какими были изначально, такими и остались. Комитет заместо добавления чегото нужного занимался документированием багофичей. И такими вещами никому не нужными как std::mask_array
Re[18]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 09.01.08 17:48
Оценка:
Здравствуйте, minorlogic, Вы писали:

EC>>Concepts эту задачу решают. Некий аналог классов типов Хаскеля.


M>К сожалению в плюсах шаблоны изначально криво встроенны , и Concepts эти слабая попытка лечения. А вылечить концептальные проблемы скорее всего не получится.


А что с шаблонами не так?
now playing: Ralph Sliwinski — Maggizahn
Re[19]: C++0x начали урезать
От: minorlogic Украина  
Дата: 09.01.08 18:58
Оценка:
Здравствуйте, EvilChild, Вы писали:

M>>К сожалению в плюсах шаблоны изначально криво встроенны , и Concepts эти слабая попытка лечения. А вылечить концептальные проблемы скорее всего не получится.


EC>А что с шаблонами не так?


То что используемый контракт налагаемый на шаблонный класс нигде явно не выражен.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[20]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 09.01.08 19:07
Оценка:
Здравствуйте, minorlogic, Вы писали:

EC>>А что с шаблонами не так?


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


Так консепты как раз эту задачу и решают или я что-то упустил?
now playing: Ralph Sliwinski — Thatz In My Brain
Re[21]: C++0x начали урезать
От: minorlogic Украина  
Дата: 09.01.08 19:12
Оценка:
Здравствуйте, EvilChild, Вы писали:

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


EC>>>А что с шаблонами не так?


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


EC>Так консепты как раз эту задачу и решают или я что-то упустил?


Нет. Они частично пытаються ее решить. К сожалению или счастью , использование концептов необязательно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[22]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 09.01.08 20:05
Оценка:
Здравствуйте, minorlogic, Вы писали:

EC>>Так консепты как раз эту задачу и решают или я что-то упустил?


M>Нет. Они частично пытаються ее решить. К сожалению или счастью , использование концептов необязательно.


Почему частично? Чего не хватает для полного счастья кроме необязательности?
now playing: Ralph Sliwinski — Dope Doreen
Re[23]: C++0x начали урезать
От: minorlogic Украина  
Дата: 10.01.08 07:20
Оценка:
Здравствуйте, EvilChild, Вы писали:

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


EC>>>Так консепты как раз эту задачу и решают или я что-то упустил?


M>>Нет. Они частично пытаються ее решить. К сожалению или счастью , использование концептов необязательно.


EC>Почему частично? Чего не хватает для полного счастья кроме необязательности?


Явного указания програмистом что используемый класс реализует некий концепт.

типа

class Customer support refCountable;
где Customer внешний класс , support некое ключевое слово, и refCountable концепт. В данном случае на форме не настаиваю , важна идея явного указания потдержки классом концепта.

В идеале я бы хотел совместить наследование интерфейсов с данным механизмом. Все это источник многочисленных технических споров, возможно я к ним не готов.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[20]: C++0x начали урезать
От: Константин Л. Франция  
Дата: 10.01.08 14:04
Оценка:
Здравствуйте, VladD2, Вы писали:

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


КЛ>>Зачем лечить мифические болезни? Ты не думал, что эта кривость для создателей было то, что нужно? Чем плох пистолет по сравнению с автоматом? Видимо тем, что он решает те же задачи, но в других ситуациях.


VD>Обожаю аналогии! Здесь уместнее будет не пистолет, а вилка. Ей тоже можно убить. Причем так как у нее 4 острых части, то теоритически она в 4 раза эффективнее любого пулемета .


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

КЛ>>Меня иногда коробит "концептность" .net generics.


VD>Хороший пример. Давай я тебе поясню на нем чем плохи шаблоны С++. Дженерики проектировались специалистами с серьезной мат.подготовкой. Они были продуманы, птестированы, подверглись крититике со стороны коммерческих программистов и в итоге были после доводки реализованы теми самыми коммерческими программистами. При этом учидывались следующие факторы:


С серьезной мат. подготовкой, понимаешь! Влад, хватит хрень всякую нести. Что там проектировать? Апполон 13? Какая еще мат. подготовка?

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

[]

Тут все правда. Но шаблоны это концептуально законченная идея. Нравится она тебе или minorlogic'у или не нравится — на ее законченность это не влияет.
Re[21]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.01.08 16:11
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>Если мне надо кого-то заколбасить на званом ужине, я рассмотрю вилку как неплохое орудие убийства, особенно если я умею ей профессионально ообращаться.


Не. Я любитель. Есть люблю ей, а так — нет.

КЛ>С серьезной мат. подготовкой, понимаешь! Влад, хватит хрень всякую нести. Что там проектировать? Апполон 13? Какая еще мат. подготовка?


The PPG group at MSR Cambridge have been designing and prototyping support for "generics" in C# and the .NET Common Language Runtime. Generics are also known as polymorphism, parameterized types, or templates.

http://research.microsoft.com/projects/clrgen/

Особо обрати внимание на год.
Кстати, один из мужиков занимавшийся дженериками разработал F#.

КЛ>Если отбросить пыл, то никакая мат подготовка и коммерческость программистов еще ничего не гарантирует.


Это уже не совсем так. В МС взяли на работу многих исследователей. В том числе тех что создали Хаскель, F# и т.п.

КЛ>Тут все правда. Но шаблоны это концептуально законченная идея. Нравится она тебе или minorlogic'у или не нравится — на ее законченность это не влияет.


Шаблоны созданы "из лучших побуждений" человеком который не имел достаточно полготовки. Их правда, что делали для того чтобы "сделать vector<T>". Ошибок было сделано уйма.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.01.08 11:29
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>Только ни одному из этих горе-специалистов не хватило сообразиловки сделать констрейнты на new с параметрами, или например простейший оператор сложения. Вот и появляются потом извраты с активатором или рефлекшеном


Это проблемы не дженериков, а системы типов дотнета. Создание объектов без передачи параметров тоже реально превращается в вызво активатора (что, естестенно не быстро).

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

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

AF>Не говоря уже о такой маленькой но жутко полезной фиче как type alias.


Это вообще проблема Шарпа. У дженирикам никаким боком не относящаяся. В тот же Немерле оные есть не смотря на полную поддержку дженириков.

AF>В общем, косяков у генериков тоже более чем достаточно.


Ты путашь косяки дженериков и того для чего они реализованы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: C++0x начали урезать
От: Andrei F.  
Дата: 11.01.08 12:21
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это проблемы не дженериков, а системы типов дотнета. Создание объектов без передачи параметров тоже реально превращается в вызво активатора (что, естестенно не быстро).


Да без разницы, что там внутри. Проблема в том, что я не могу просто написать new T(var1, var2), а вместо этого мне приходится черт-те что городить, чтобы решить эту крайне простую задачу. Попробуй ка без MSDN вспомни, какие параметры здесь надо написать, чтобы сделать то же самое через явный вызов активатора?

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


А не подскажешь, как получить делегат на оператор сложения двух чисел? Почему они не сделали интерфейс IAddable, на самый уж худой конец?
И почему нельзя записать в констрейнте System.Enum? Он то кому мог помешать?

VD>Это просто другой подход. Тебе не нужно позволять вызвать у типов операторы и тому подобное. Вместо этого ты можешь просто передать нужные фунции или интерфейсы в качестве параметров.


Это не подход, это костыль. Причем кривой.
Re[23]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.01.08 12:56
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>Да без разницы, что там внутри. Проблема в том, что я не могу просто написать new T(var1, var2), а вместо этого мне приходится черт-те что городить, чтобы решить эту крайне простую задачу. Попробуй ка без MSDN вспомни, какие параметры здесь надо написать, чтобы сделать то же самое через явный вызов активатора?


Согласен, неудобно. Но не смертельно. Тут нужно использовать фабрики классов или фабричные метода (инициализируемые лямбдами).

AF>А не подскажешь, как получить делегат на оператор сложения двух чисел?


Подскажу: "_ + _". Его тип будет выведен в автомате. Если нужно именно целых, то можно так: "_ _ : int + _ : int".
В менее правильных языках это будет выглядить так: "(x, y) => x + y".

AF> Почему они не сделали интерфейс IAddable, на самый уж худой конец?

Там начинаются проблемы с полиморфизмом. Ведь по уму нужно будет делать интерфейсы для всех сочетаний типов (IAddable<int, double>, IAddable<short, int>, ...), а это вызвает две проблемы 1) комбинаторный врыв, 2) невозможность расширения уже определенных интерфейсов.

Правильное решение было придумано в Хаскеле. Там придумали классы типов. Это что-то типа интерфейсов, но их не реализуют в тиах, а воплощают для типов. Если, например, у тебя есть типы int и double и теб нужно применить их где-то где поддерживается класс типов Addable, то тбе достаточно создать воплощение Addable для Addable<int, double> (псевда-синтаксис, аля Шарп).

AF>И почему нельзя записать в констрейнте System.Enum? Он то кому мог помешать?


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

VD>>Это просто другой подход. Тебе не нужно позволять вызвать у типов операторы и тому подобное. Вместо этого ты можешь просто передать нужные фунции или интерфейсы в качестве параметров.


AF>Это не подход, это костыль. Причем кривой.


Нет. Это как раз отличный подход. Они универсально действует везде, а не только тут. На его основе можно офигительно просто писать программы кторые при этом будут очень хорошо читаться.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: C++0x начали урезать
От: Курилка Россия http://kirya.narod.ru/
Дата: 14.01.08 13:08
Оценка:
Здравствуйте, VladD2, Вы писали:

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


AF>>А не подскажешь, как получить делегат на оператор сложения двух чисел?


VD>Подскажу: "_ + _". Его тип будет выведен в автомате. Если нужно именно целых, то можно так: "_ _ : int + _ : int".

VD>В менее правильных языках это будет выглядить так: "(x, y) => x + y".

У мсье есть некий "истинный критерий святой правильности"?
Re[25]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.01.08 13:12
Оценка:
Здравствуйте, Курилка, Вы писали:

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


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


AF>>>А не подскажешь, как получить делегат на оператор сложения двух чисел?


VD>>Подскажу: "_ + _". Его тип будет выведен в автомате. Если нужно именно целых, то можно так: "_ _ : int + _ : int".

VD>>В менее правильных языках это будет выглядить так: "(x, y) => x + y".

К>У мсье есть некий "истинный критерий святой правильности"?


А ты до сих пор этого не знал?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[25]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.01.08 13:21
Оценка:
Здравствуйте, Курилка, Вы писали:

К>У мсье есть некий "истинный критерий святой правильности"?


Да.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: C++0x начали урезать
От: Курилка Россия http://kirya.narod.ru/
Дата: 14.01.08 13:21
Оценка:
Здравствуйте, eao197, Вы писали:

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


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


К>>У мсье есть некий "истинный критерий святой правильности"?


E>А ты до сих пор этого не знал?


Ну может забыл и ещё люди меняются (лучше, конечно, когда в положительную сторону).
Re[24]: C++0x начали урезать
От: Andrei F.  
Дата: 14.01.08 13:33
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Согласен, неудобно. Но не смертельно. Тут нужно использовать фабрики классов или фабричные метода (инициализируемые лямбдами).


VD>Подскажу: "_ + _". Его тип будет выведен в автомате. Если нужно именно целых, то можно так: "_ _ : int + _ : int".

VD>В менее правильных языках это будет выглядить так: "(x, y) => x + y".

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

VD>Там начинаются проблемы с полиморфизмом. Ведь по уму нужно будет делать интерфейсы для всех сочетаний типов (IAddable<int, double>, IAddable<short, int>, ...), а это вызвает две проблемы 1) комбинаторный врыв, 2) невозможность расширения уже определенных интерфейсов.


Ну например, для интерфейса IConvertible им эти проблемы почему-то не помешали. А здесь сделать то же самое — ну никак
В конце концов, можно было определить только версию интерфейса с аргументом того же типа, что и сам объект. Так они даже и этого не сделали.

VD>Нет. Это как раз отличный подход. Они универсально действует везде, а не только тут. На его основе можно офигительно просто писать программы кторые при этом будут очень хорошо читаться.


офигительно просто — это если я мог бы делать так:
T var1, var2;
// .......
T res = var1 + var2;

А когда вместо этого мне приходится плясать с бубном, чтобы просто сложить два числа, то это хрень полная, а не "отличный подход"
Re[25]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.01.08 14:15
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>Ну например, для интерфейса IConvertible им эти проблемы почему-то не помешали. А здесь сделать то же самое — ну никак

AF>В конце концов, можно было определить только версию интерфейса с аргументом того же типа, что и сам объект. Так они даже и этого не сделали.

IConvertible — это пример безгрмотного проектирования. Когда его создавали, то не было даже дженериков. На сегодня я бы его вообще запретил. Он не расширяем и избыточен одновременно. Надо было ввести один делегат и передавать фукнции конвертации куда нужно по ссылке.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: C++0x начали урезать
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.01.08 08:53
Оценка:
Здравствуйте, Курилка, Вы писали:

К>У мсье есть некий "истинный критерий святой правильности"?


Если тебе чем то не нравится Влад, это совершенно не повод усиленно провоцировать здесь флейм.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[26]: C++0x начали урезать
От: Курилка Россия http://kirya.narod.ru/
Дата: 23.01.08 09:00
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


К>>У мсье есть некий "истинный критерий святой правильности"?


Извиняюсь, если кого-то задел мой вопрос.
Re[31]: C++0x начали урезать
От: Andrei F.  
Дата: 01.02.08 06:23
Оценка:
Здравствуйте, eao197, Вы писали:

E>Мосье оракул?


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

E>А языки типа Scala или Nice вы куда вписываете?


Scala — это самый лучший и совершенный паровоз. Само по себе неплохо, но когда уже появились первые двигатели внутренного сгорания — совершенно бесполезно. Nice очень похож, к тому же развитие в последнее время практически остановилось, судя по данным на сайте.
Re[32]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.02.08 06:35
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


E>>Мосье оракул?


AF>Нет, мосье просто анализирует данные.


И какие данные? Учитывается ли опыт Lisp-ов?

E>>А языки типа Scala или Nice вы куда вписываете?


AF>Scala — это самый лучший и совершенный паровоз. Само по себе неплохо, но когда уже появились первые двигатели внутренного сгорания — совершенно бесполезно.


Доказательство по аналогии...
Тем не менее хотелось бы услышать более конкретные причины, по которым у Scala нет будущего.

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


В Nice автор реализовал все, что хотел. Сейчас это весьма качественный и стабильный язык, дело за использованием. Будет использование, будет и дальнейшее развитие. Так сам автор Nice говорит:

If you like the language, it is of course an
option to use it more intensively, if you realize there is not the
same guarantee of future development as for a "big" language.
Basically it depends on whether a community will grow and contribute
to it, and maybe you can also help with that. I am in any case willing
to look at bugs and fix them as much as possible.


Кстати, последний релиз Nice вышел всего несколько месяцев назад -- в ноябре 2007.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[36]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.02.08 13:14
Оценка:
Здравствуйте, Andrei F., Вы писали:

<...обычное безсодержательное словоблудие поскипано, хотя над отсутствием интеропа у D поулыбался...>

E>>Пределу сложности чего?

E>>Современные языки сложно разрабатывать? На примере чего это видно? Разве были жалобы от Хальсенберга о том, что они C# 3.0 делали на пределе возможностей? Или может быть Одерски заявил, что они больше не в состоянии развивать Scala? Что-то не припомню такого, наоборот, релизы языка выходят с завидной стабильностью и переодичностью.

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

E>>Или может речь идет о пределе сложности восприятия языка пользователем? Мол столько фич насовали в язык, что мало кто способен с ними разобраться. Так а чем Nemerle здесь лучше?


AF>Речь идет именно о разработке. А лучше он тем, что силами намного меньшей команды разработано намного больше поелзных возможностей.


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

E>>Да посмотрите. А то по вашим словам Nice очень похож на Scala. Хотя из похожести там только похожий набор ключевых слов: let, var, class, for, ...


AF>А какие принципиальные отличия?


Ну хотя бы тем, что Nice -- не функциональный язык программирования.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[38]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.02.08 14:13
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>Так что, в D уже появился интероп с С++? И как это выглядит?


В оригинале было:

Пока не будет удобного и надежного интеропа с другими языками (как минимум — тем же С++), D так и будет оставаться игрушкой для фанатов. Да и ниша самого С++ постоянно уменьшается.


Интероп с другими языками в том числе и с C++ в D сделан так же, как и в самом C++ -- через C-шный интерфейс. С-шные библиотеки прозначно цепляются к D, С++ные библиотеки, обернутые в C-шный API спокойно цепляются к D, D-шные библиотеки, обернутые в С-шный API спокойно цепляются к C++.

Хотя у .NET/Windows-программистов под интеропом, наверное, понимается что-нибудь другое. Только то, что работает в рамках CLR и только под Windows.

E>>Я таки услышу ответ на вопрос о том, к пределу какой сложности приближается разработка современных языков программирования?


AF>Я надеюсь, мне не придется читать лекцию о разнице между монолитными и модульными системами?


Ну, если посмотреть на Windows и Linux, и сравнить их с модульными Hurd, Plan9 и Minix3, то интересно было бы послушать, чем же на практике модульные системы лучше монолитных.

Однако, речь не о том. Лучше было бы просто ответить на прямой вопрос.
Но я так понял, что речь идет именно о том, что сложность разработки современных ЯП приближается к пределу. И я так понял, что к пределу возможностей разработчиков.

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

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


AF>Меньше проблем в разработке языка — больше времени на обдумывание и проектирование. Лучше продуман язык — удобнее его использовать. И так далее.


Э-э-э. Тут как бы не все так очевидно. Вот вроде как на макросах был реализован DesignByContract, да только если сравнить его в аналогичным в Eiffel, то оказывается, что не все же сделано. Например, есть ли доступ к old-значениям в пост-условиях? И как реализовано наследование пред-условий?

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

AF>А то за некоторые "решения" в C# так и хочется разработчикам руки пообрывать.


Может пора уже избавляться от юношеского максимализма? А то от С++ воротит, разработчикам C# руки хочется поотрывать. Пора бы принимать жизнь такой, какая она есть.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[30]: C++0x начали урезать
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.02.08 19:29
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>Это вероятное будущее для динозавров вроде D и ему подобных. И даже не вероятное, а практически гарантированное.

AF>А настоящее будущее — за Немерле или другими языками, которые будут устроены по тому же принципу. Если, к примеру, макросы встроят в C#, то это тоже будет вполне неплохо.

Боюсь, в плане будущего конкретно D заметно благополучнее, чем конкретно Nemerle просто ввиду размера девелоперской тусовки вокруг того и другого.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[35]: C++0x начали урезать
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.02.08 19:29
Оценка:
Здравствуйте, eao197, Вы писали:

E>Пределу сложности чего?

E>Современные языки сложно разрабатывать? На примере чего это видно? Разве были жалобы от Хальсенберга о том, что они C# 3.0 делали на пределе возможностей?

Господи, ну сколько можно искажать его фамилию. Хейлберг его зовут.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[36]: C++0x начали урезать
От: Курилка Россия http://kirya.narod.ru/
Дата: 01.02.08 20:09
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


E>>Пределу сложности чего?

E>>Современные языки сложно разрабатывать? На примере чего это видно? Разве были жалобы от Хальсенберга о том, что они C# 3.0 делали на пределе возможностей?

AVK>Господи, ну сколько можно искажать его фамилию. Хейлберг его зовут.


Может всёж Хейлсберг?
Re[38]: C++0x начали урезать
От: FR  
Дата: 02.02.08 04:48
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>Это хорошо, что ты его поскипал. Тебе не пришлось его писать, мне не пришлось его читать. Молодец

AF>Так что, в D уже появился интероп с С++? И как это выглядит?

http://www.digitalmars.com/d/2.0/cpp_interface.html
http://www.digitalmars.com/d/2.0/COM.html
Re[37]: C++0x начали урезать
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.02.08 10:13
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Может всёж Хейлсберг?


Опечатка По ссылке правильно
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[39]: C++0x начали урезать
От: Andrei F.  
Дата: 04.02.08 11:22
Оценка:
Здравствуйте, eao197, Вы писали:

E>Интероп с другими языками в том числе и с C++ в D сделан так же, как и в самом C++ -- через C-шный интерфейс. С-шные библиотеки прозначно цепляются к D, С++ные библиотеки, обернутые в C-шный API спокойно цепляются к D, D-шные библиотеки, обернутые в С-шный API спокойно цепляются к C++.


Иными словами, нужно делать обертки на каждый метод с обеих сторон, в D и в C++. Классы — эмулировать.
Я могу назвать такой "интероп" как угодно, но только не удобным или надежным.

E>Хотя у .NET/Windows-программистов под интеропом, наверное, понимается что-нибудь другое. Только то, что работает в рамках CLR и только под Windows.


Ну раз ты первый об этом заговорил, мне нравится как сделан интероп в C++/CLI.
А что он реализован только под Windows — не очень хорошо, но мне это проблем не создает.

E>Вот только не понятно, на основании чего сделан такой вывод. Свидельства подобной ситуации можно увидеть?


Имеющий глаза да увидит.

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


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

E>Пора бы принимать жизнь такой, какая она есть.


То есть, отказаться от надежды что-то изменить? Ну уж нет. Становиться ментальным старичком я не собираюсь.
Re[39]: C++0x начали урезать
От: Andrei F.  
Дата: 04.02.08 11:28
Оценка:
Здравствуйте, FR, Вы писали:

FR>http://www.digitalmars.com/d/2.0/cpp_interface.html


Use the limited ability described here to connect directly to C++ functions and classes.

Вот этот пункт — это интересно, не знал что такая возможность есть. Но реально она настолько "limited", судя по описанию, что использовать ее практически нереально.
Re[40]: C++0x начали урезать
От: FR  
Дата: 04.02.08 12:01
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


FR>>http://www.digitalmars.com/d/2.0/cpp_interface.html


AF>

Use the limited ability described here to connect directly to C++ functions and classes.

AF>Вот этот пункт — это интересно, не знал что такая возможность есть. Но реально она настолько "limited", судя по описанию, что использовать ее практически нереально.

Практически как раз вполне реально, но это не так важно, важно то что движение есть, раньше насколько я знаю авторы языка с этой проблемоой просто посылали
Re[40]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.02.08 13:13
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


E>>Интероп с другими языками в том числе и с C++ в D сделан так же, как и в самом C++ -- через C-шный интерфейс. С-шные библиотеки прозначно цепляются к D, С++ные библиотеки, обернутые в C-шный API спокойно цепляются к D, D-шные библиотеки, обернутые в С-шный API спокойно цепляются к C++.


AF>Иными словами, нужно делать обертки на каждый метод с обеих сторон, в D и в C++. Классы — эмулировать.

AF>Я могу назвать такой "интероп" как угодно, но только не удобным или надежным.

Ну т.е. для Ruby, Python, Eiffel, OCaml и Erlang такой способ интеграции с C/C++ считается нормальным, а для D почему-то нет?

E>>Хотя у .NET/Windows-программистов под интеропом, наверное, понимается что-нибудь другое. Только то, что работает в рамках CLR и только под Windows.


AF>Ну раз ты первый об этом заговорил, мне нравится как сделан интероп в C++/CLI.

AF>А что он реализован только под Windows — не очень хорошо, но мне это проблем не создает.

Ну то есть, вне .NET/Windows жизни ты не видишь. Так и запишем.
А разве C++/CLI -- это C++?
И если уж речь зашла об .NET-е, что в D такого принципиального есть, что не позволяет, при желании, сделать вариант D для .NET-а? Если уж из C++ смогли сделать C++/CLI, то из D почему нельзя?

E>>Вот только не понятно, на основании чего сделан такой вывод. Свидельства подобной ситуации можно увидеть?


AF>Имеющий глаза да увидит.


Дык а куда смотреть-то? Вот сейчас идет разработка Python3K, Ruby 2, D 2.0, Scala 2.7 -- не видать там Nemerle-вых ушей. В прошлом году были новые релизы C#, Erlang, OCaml -- и там не видно.

Зато вот те, кто затеял возню с микроядром и метапрограммированием, потеряли мотивацию к дальнейшей разработке.

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


AF>Если учесть размер команды, то при разработке на языке без макросов никаких контрактов не было бы вообще.


В Sign# есть, в D есть, в Nice есть такие же контракты. И команды там были не на много больше, чем у Nemerle.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[41]: C++0x начали урезать
От: Andrei F.  
Дата: 04.02.08 13:40
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ну т.е. для Ruby, Python, Eiffel, OCaml и Erlang такой способ интеграции с C/C++ считается нормальным, а для D почему-то нет?


Может быть — потому что никто не позиционирует Ruby, Python, Eiffel, OCaml и Erlang как замену С++, да и вообще у них ниша совсем другая?

E>Ну то есть, вне .NET/Windows жизни ты не видишь. Так и запишем.


Вижу. Но не вижу смысла тратить на нее усилия. Пока что.

E>А разве C++/CLI -- это C++?


Это его надмножество.

E>И если уж речь зашла об .NET-е, что в D такого принципиального есть, что не позволяет, при желании, сделать вариант D для .NET-а? Если уж из C++ смогли сделать C++/CLI, то из D почему нельзя?


Можно. И полноценный интероп с С++ в нем тоже можно сделать. Когда сделают — тогда и будет о чем говорить

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


А он не является "единственным правильным". Он просто самый перспективный. Но это нельзя доказать. Никак. Единственный способ — это подождать и проверить.
Re[42]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.02.08 13:48
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


E>>Ну т.е. для Ruby, Python, Eiffel, OCaml и Erlang такой способ интеграции с C/C++ считается нормальным, а для D почему-то нет?


AF>Может быть — потому что никто не позиционирует Ruby, Python, Eiffel, OCaml и Erlang как замену С++, да и вообще у них ниша совсем другая?


Т.е. вы хотите сказать, что ни Eiffel, ни OCaml ну ни капельки не претендуют на нишу C++?

E>>И если уж речь зашла об .NET-е, что в D такого принципиального есть, что не позволяет, при желании, сделать вариант D для .NET-а? Если уж из C++ смогли сделать C++/CLI, то из D почему нельзя?


AF>Можно.


Уже прогресс.

AF> И полноценный интероп с С++ в нем тоже можно сделать.


Нельзя. Если бы вы внимательно посмотрели бы на ссылку, данную вам FR, то вы бы увидели:

C++ Templates

D templates have little in common with C++ templates, and it is very unlikely that any sort of reasonable method could be found to express C++ templates in a link-compatible way with D.

This means that the C++ STL, and C++ Boost, likely will never be accessible from D.

Без поддержки STL никакой интероп с C++ не будет полноценным.

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


AF>А он не является "единственным правильным". Он просто самый перспективный. Но это нельзя доказать. Никак. Единственный способ — это подождать и проверить.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[42]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.02.08 13:58
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


E>>В Sign# есть, в D есть, в Nice есть такие же контракты. И команды там были не на много больше, чем у Nemerle.


K>Над статической проверкой контрактов в Spec# работала команда специалистов, превышающая, насколько мне известно, количество основных разработчиков D, Nice и Nemerle вместе взятых.


Поэтому для Spec# нужно грузить отдельную написанную на Java библиотеку, которая доказательством и занимается? Причем, насколько я помню, написана она была как раз не командой Spec#, а в Hewlett-Pakard.

Тем не менее, вопрос был в другом. Для нормальной поддержки Design By Contract в постусловиях нужно реализовать доступ к значениям, которые некоторые атрибуты/методы имели до запуска метода. В Eiffel для этого даже специальное ключевое слово в постусловиях используется -- old. Можно ли это ключевое слово поддержать в Nemerle, где контракты реализованы на макросах?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[37]: C++0x начали урезать
От: Трурль  
Дата: 04.02.08 14:54
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Может всёж Хейлсберг?

Скорее, Хайльсберг
Re[42]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.02.08 15:45
Оценка:
Здравствуйте, WolfHound, Вы писали:

AF>>>А что он реализован только под Windows — не очень хорошо, но мне это проблем не создает.

E>>Ну то есть, вне .NET/Windows жизни ты не видишь. Так и запишем.
WH>Демагог млин.
WH>Из того что сказал Andrei F. это не слудет.

А что из его слов следует?

E>>Зато вот те, кто затеял возню с микроядром и метапрограммированием, потеряли мотивацию к дальнейшей разработке.

WH>Они сделали компилятор продакшен качества в отличии от остальных. Даже в C# с их ресурсами багов как минимум не меньше.
WH>И это при том что в nemerle один из самых мощных алгоритмов вывода типов.

WH>Нука покажи мне язык с системой типов не Hindley–Milner который на такое способен.

WH>Да и вобще обрати внимание на то с каким цинизмом написана данная функция.

Прошу простить мне мою неграмотность, но я ничего не понял ни в приведенном примере. Да и про систему Hindley-Milner я знаю лишь то, что она есть.

Однако, из виденных мной исходников, наиболее читабельными при сопровождении оказывались программы на Eiffel, где никакого вывода типов нет вообще, ну т.е. в принципе. Так что я рад за мощность системы вывода типов в Nemerle и вообще желаю этому языку не помереть тихой смертию. Но время должно доказать состоятельность Nemerle для использования в самых обычных проектах.

WH>Кстати это кусок мониторинга продакшен кластера.


WH>А в этом случае макрос [Memoize] превращает алгоритм из экспоненциального в линейный.

WH>Сколько времени нужно просить автора D чтобы он добавил [Memoize]?

ХЗ. По моему опыту, автор D делает то, что он сам считает нужным.
А что, этот алгоритм ну никак без Memoize запрограммировать нельзя?

E>>В Sign# есть, в D есть, в Nice есть такие же контракты. И команды там были не на много больше, чем у Nemerle.

WH>Те контракты что в немерле сделаны чисто по приколу.
WH>Если они тебе не нравятся ты можешь сделать правильные контракты.
WH>Это тебе позволяет микроядро и метапрограммирование.

Вообще-то это странный подход к пользователю -- вот тебе конструктор и делай из него что тебе нужно. Нафиг мне этот конструктор? У меня своих задач хватает, а вокруг полно более качественно сделанных инструментов, которые позволяют их решать. А когда я беру инструмент, мне фиолетово, как он сделан, мне его качества важны. И если кто-то предоставляет инструмент нужно качества, но сделанный не по "передовой" технологии, то по мне это скорее опровергает "передовость" той самой технологии.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[31]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.02.08 16:00
Оценка:
Здравствуйте, eao197, Вы писали:

AF>>Это вероятное будущее для динозавров вроде D и ему подобных. И даже не вероятное, а практически гарантированное.

AF>>А настоящее будущее — за Немерле или другими языками, которые будут устроены по тому же принципу.

E>Мосье оракул?


E>А языки типа Scala или Nice вы куда вписываете?


Скала как раз намного ближе к Немерлу нежели к Ди. Приделать ей макросы и скорости добавить, будет то же Немерле вид в профиль.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: C++0x начали урезать
От: FR  
Дата: 04.02.08 16:08
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Немерле же имеет одну особенность. Он практически является сабсэтом C#-а. А уж для него налажено обучение по полной программе.


А плюс ли это вообще?
Объем знаний и умений чтобы хорошо писать используя функциональную парадигму гораздо больше чем объем нужный чтобы освоить еще один язык с новым синтаксисом.
Re[43]: C++0x начали урезать
От: WolfHound  
Дата: 04.02.08 16:13
Оценка:
Здравствуйте, eao197, Вы писали:

E>Прошу простить мне мою неграмотность, но я ничего не понял ни в приведенном примере. Да и про систему Hindley-Milner я знаю лишь то, что она есть.

И что там не понятно?
Не считая System.Diagnostics.Process() и компанию.
ИМХО простейшей код из серии что вижу то пою.

E>Однако, из виденных мной исходников, наиболее читабельными при сопровождении оказывались программы на Eiffel, где никакого вывода типов нет вообще, ну т.е. в принципе.

Ну а моя практика показывает что из всех языков на которых я писал проще всего править код на немерле.
Причем вывод типов одна из главных причин этого.
В принципе примерно тоже самое можно делать при динамической типизации но у нее есть большой недостаток: нет контроля типов во время компиляции. А это важно ибо ловит довольно много ошибок.

E>Так что я рад за мощность системы вывода типов в Nemerle и вообще желаю этому языку не помереть тихой смертию.

Ну ему точно будет не хуже чем Eiffel'ю...

E>Но время должно доказать состоятельность Nemerle для использования в самых обычных проектах.

А что тут доказывать то?
Он заведомо не хуже C#.
Единственное что интелисенс пока слабее.

E>ХЗ. По моему опыту, автор D делает то, что он сам считает нужным.

А тут я могу сделать то что я считаю нужным.

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

Можно.
Но код будет далеко не таким прозрачным.
Почитай условие и решение. И увидишь что решение практически переписанное на языке программирования условие.

E>Вообще-то это странный подход к пользователю -- вот тебе конструктор и делай из него что тебе нужно. Нафиг мне этот конструктор? У меня своих задач хватает, а вокруг полно более качественно сделанных инструментов, которые позволяют их решать. А когда я беру инструмент, мне фиолетово, как он сделан, мне его качества важны. И если кто-то предоставляет инструмент нужно качества, но сделанный не по "передовой" технологии, то по мне это скорее опровергает "передовость" той самой технологии.

Дело в том что нет инструментов на все случаи жизни.
Ну нету.
Иногда приходится под задачу делать и вот тут то что язык предостовляет конструктор (и кучу уже готовых инструментов которые можно использовать, а можно и нет) дает большие преимущества.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[44]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.02.08 16:23
Оценка:
Здравствуйте, WolfHound, Вы писали:

E>>Так что я рад за мощность системы вывода типов в Nemerle и вообще желаю этому языку не помереть тихой смертию.

WH>Ну ему точно будет не хуже чем Eiffel'ю...

Ну, когда средства разработки для Nemerle будут продаваться и окупать вложенные в них усилия, тогда и можно будет сравнивать успешность Nemerle и Eiffel-я.

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

WH>Можно.
WH>Но код будет далеко не таким прозрачным.
WH>Почитай условие и решение. И увидишь что решение практически переписанное на языке программирования условие.

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

WH>Дело в том что нет инструментов на все случаи жизни.

WH>Ну нету.
WH>Иногда приходится под задачу делать и вот тут то что язык предостовляет конструктор (и кучу уже готовых инструментов которые можно использовать, а можно и нет) дает большие преимущества.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[38]: C++0x начали урезать
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.02.08 16:47
Оценка:
Здравствуйте, Трурль, Вы писали:

К>>Может всёж Хейлсберг?

Т>Скорее, Хайльсберг

Ну это вряд ли. Сам он произносит примерно как Хёйлсберг.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[45]: C++0x начали урезать
От: WolfHound  
Дата: 04.02.08 16:51
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ну, когда средства разработки для Nemerle будут продаваться и окупать вложенные в них усилия, тогда и можно будет сравнивать успешность Nemerle и Eiffel-я.

Сравнивать успешность языков можно только по колличеству проектов на них сделанных.

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

E>Где нибудь эта задача еще описана с тестовыми данными?
http://projecteuler.net/index.php?section=problems&amp;id=178
Легче стало?

E>Если под инструментом понимать язык, то я не согласен с тем, что сложные задачи нужно модифицировать хост-язык собственными силами. Будь то Lisp или Nemerle. Кому-то этот подход может нравится, но я не из их числа.

Дело в том что в случае с немерле в отличии от лиспа в подавляющем большинстве случаев язык модифицировать не надо.
Лично я пока еще по делу не написал ни одного макроса. (ибо пока не писал на немерле ничего действительно большого)
Но скажем на прошлой работе если бы тот проект делался на немерле, а не на C# то по крайней мере одну макру я бы написал. Тем самым избавив себя и окружающих от кучи гемороя.
В томже компиляторе немерла есть несколько макросов которые добавляют к AST кучу тупых но весьма объемных методов. Писать их руками это полный звиздец. Генерить текст еще больший геморой.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[46]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.02.08 18:38
Оценка:
Здравствуйте, WolfHound, Вы писали:

E>>Ну, когда средства разработки для Nemerle будут продаваться и окупать вложенные в них усилия, тогда и можно будет сравнивать успешность Nemerle и Eiffel-я.

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

Ну по этому показателю Nemerle до Eiffel-я еще расти и расти, и расти, и расти...

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

E>>Где нибудь эта задача еще описана с тестовыми данными?
WH>http://projecteuler.net/index.php?section=problems&amp;id=178
WH>Легче стало?

Не-а, тестовых данных нет, проверять не на чем

E>>Если под инструментом понимать язык, то я не согласен с тем, что сложные задачи нужно модифицировать хост-язык собственными силами. Будь то Lisp или Nemerle. Кому-то этот подход может нравится, но я не из их числа.

WH>Дело в том что в случае с немерле в отличии от лиспа в подавляющем большинстве случаев язык модифицировать не надо.
WH>Лично я пока еще по делу не написал ни одного макроса. (ибо пока не писал на немерле ничего действительно большого)
WH>Но скажем на прошлой работе если бы тот проект делался на немерле, а не на C# то по крайней мере одну макру я бы написал. Тем самым избавив себя и окружающих от кучи гемороя.
WH>В томже компиляторе немерла есть несколько макросов которые добавляют к AST кучу тупых но весьма объемных методов. Писать их руками это полный звиздец. Генерить текст еще больший геморой.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[47]: C++0x начали урезать
От: WolfHound  
Дата: 04.02.08 18:54
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ну по этому показателю Nemerle до Eiffel-я еще расти и расти, и расти, и расти...

Напомни когда там Eiffel появился...

E>Не-а, тестовых данных нет, проверять не на чем

Если ты залогинен там есть такое маленькое окошечко куда ответ скормить можно...
В любом случае можно откомпилить мой пример заменив Sum64() на болие длинный аналог Fold(0L, (n, s) => s + n)

E>Тогда в чем смысл вообще всей этой шумихи -- микроядро, расширяемость и пр. Если подавляющее большинство разработчиков используют готовые вещи в языке, то какая разница, на макросах эти вещи сделаны или нет?

Проблема в том что когда вдруг стандартных вещей не хватает (а это иногда случается) то только микроядро с макросами и спасает.
Иначе куча траха на ровном месте.
В любом случае немерле сам по себе гораздо болие приятный язык нежели всякие там C#пы.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[46]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 04.02.08 19:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Но скажем на прошлой работе если бы тот проект делался на немерле, а не на C# то по крайней мере одну макру я бы написал. Тем самым избавив себя и окружающих от кучи гемороя.

Расскажи подробнее о проблеме.
now playing: Autechre — 90101-5l-l
Re[47]: C++0x начали урезать
От: WolfHound  
Дата: 04.02.08 19:58
Оценка:
Здравствуйте, EvilChild, Вы писали:

WH>>Но скажем на прошлой работе если бы тот проект делался на немерле, а не на C# то по крайней мере одну макру я бы написал. Тем самым избавив себя и окружающих от кучи гемороя.

EC>Расскажи подробнее о проблеме.
Жестокое скрещивание ежа с ужом и моржом. Изменить дизайн было нельзя ибо это выходило боком в гаааааааааараздо болие большом объеме кода.
Короче copy&paste в промышленных объемах...
Если бы были макросы то этот копипаст сделали бы макросы.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[48]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 04.02.08 20:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Жестокое скрещивание ежа с ужом и моржом. Изменить дизайн было нельзя ибо это выходило боком в гаааааааааараздо болие большом объеме кода.

WH>Короче copy&paste в промышленных объемах...
Проблему нельзя описать коротко или влом это делать?
Спрашиваю без всякого стёба.
WH>Если бы были макросы то этот копипаст сделали бы макросы.
Моих ясновидческих способностей нехватило, чтобы вкурить о чём ты...
now playing: Autechre — Outh9X
Re[49]: C++0x начали урезать
От: WolfHound  
Дата: 04.02.08 20:23
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Проблему нельзя описать коротко или влом это делать?

EC>Спрашиваю без всякого стёба.
Коротко нельзя да и НДА.

EC>Моих ясновидческих способностей нехватило, чтобы вкурить о чём ты...

В кучу классов пришлось скопировать кучу кода с минимальными переделками от класса к классу.
Если бы были макросы то этой тупой работой занимались бы они.
Причем сам понимаешь поддерживать такой код куда проще ибо для того чтобы что-то поменять нужно менять в одном месте, а не в паре десятков.
Благо этот ужос удалось локализовать в одной сборке.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[50]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 04.02.08 21:01
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Коротко нельзя да и НДА.

Тогда как аргумент в пользу макросов это звучит малоубедительно.
Давай лучше так — если есть время глянь здесь и скажи позволят ли макросы как-то улучшить решение там описанное.
Или можно ли на них реализовать это?
now playing: Autechre — Theswere
Re[43]: C++0x начали урезать
От: Andrei F.  
Дата: 05.02.08 05:10
Оценка:
Здравствуйте, eao197, Вы писали:

E>Т.е. вы хотите сказать, что ни Eiffel, ни OCaml ну ни капельки не претендуют на нишу C++?


"C++ successor" их точно не называли.

E>Нельзя. Если бы вы внимательно посмотрели бы на ссылку, данную вам FR, то вы бы увидели:

E>

E>C++ Templates

E>D templates have little in common with C++ templates, and it is very unlikely that any sort of reasonable method could be found to express C++ templates in a link-compatible way with D.

E>This means that the C++ STL, and C++ Boost, likely will never be accessible from D.

E>Без поддержки STL никакой интероп с C++ не будет полноценным.

Чем-то это мне напоминает:
http://rsdn.ru/Forum/Message.aspx?mid=2807685&amp;only=1
Автор: Дм.Григорьев
Дата: 22.01.08


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

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


Правильно, это моя точка зрения. А какие могли быть другие варианты? Божественное откровение, выбитое на каменных скрижалях?
Re[44]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.02.08 07:06
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


E>>Т.е. вы хотите сказать, что ни Eiffel, ни OCaml ну ни капельки не претендуют на нишу C++?


AF>"C++ successor" их точно не называли.


А что, звание "С++ successor" автоматически подразумевает совместимость с C++?
Sun в свое время Java рекламировал как "исправленный C++", тем не менее, об прозрачном интеропе с C++ ни тогда, ни сейчас речи не было.

E>>Нельзя. Если бы вы внимательно посмотрели бы на ссылку, данную вам FR, то вы бы увидели:

E>>

E>>C++ Templates

E>>D templates have little in common with C++ templates, and it is very unlikely that any sort of reasonable method could be found to express C++ templates in a link-compatible way with D.

E>>This means that the C++ STL, and C++ Boost, likely will never be accessible from D.

E>>Без поддержки STL никакой интероп с C++ не будет полноценным.

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

AF>http://rsdn.ru/Forum/Message.aspx?mid=2807685&amp;only=1
Автор: Дм.Григорьев
Дата: 22.01.08


AF>В данном случае, автоматический маршалинг данных между основными типами коллекций STL и соответствующими типами D — этого было бы достаточно для большинства случаев.


Вы хоть сами-то представляете во что это выльется?
Если у меня C++ный класс возвращает ссылку на std::map с 30000 значений внутри, какая польза будет от маршалинга?

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


AF>Правильно, это моя точка зрения.


Если бы вы сразу написали:

А настоящее будущее, по-моему, — за Немерле или другими языками, которые будут устроены по тому же принципу.

то вопросов бы не было.

AF> А какие могли быть другие варианты?


Например, ссылки на высказывание авторитетных в этой области разработчиков. Например, если бы в каком-нибудь интервью об этом сказал Гослинг, Страуструп, Хёйсберг, Ксавье Лерой, Мартин Одерски Бертран Мейер или еще кто-нибудь из разработчиков языков программирования. Или какая-нибудь инсайдерская информация в блоге кого-нибудь из разработчиков C# или Java, или Scala, или Eiffel или OCaml о том, что "блин, забабахались мы с последним релизом языка, чуть живы остались, пора что-то в консерватории править". Тогда хоть какая-то объективная информация к размышлению была бы.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[45]: C++0x начали урезать
От: Andrei F.  
Дата: 05.02.08 07:45
Оценка:
Здравствуйте, eao197, Вы писали:

E>А что, звание "С++ successor" автоматически подразумевает совместимость с C++?

E>Sun в свое время Java рекламировал как "исправленный C++", тем не менее, об прозрачном интеропе с C++ ни тогда, ни сейчас речи не было.

Занять нишу С++ у них и не получилось. Ни тогда, ни сейчас. Успех Явы произошел совсем не в той области, где ожидали ее разработчики.

E>Вы хоть сами-то представляете во что это выльется?

E>Если у меня C++ный класс возвращает ссылку на std::map с 30000 значений внутри, какая польза будет от маршалинга?

А никто не говорит, что эти значения обязательно надо копировать. Сделать обертку, которая будет перенаправлять вызовы оригинальному объекту — не проблема. Во всяком случае, для автора компилятора, у которого все карты в руках.

E>Например, ссылки на высказывание авторитетных в этой области разработчиков. Например, если бы в каком-нибудь интервью об этом сказал Гослинг, Страуструп, Хёйсберг, Ксавье Лерой, Мартин Одерски Бертран Мейер или еще кто-нибудь из разработчиков языков программирования. Или какая-нибудь инсайдерская информация в блоге кого-нибудь из разработчиков C# или Java, или Scala, или Eiffel или OCaml о том, что "блин, забабахались мы с последним релизом языка, чуть живы остались, пора что-то в консерватории править". Тогда хоть какая-то объективная информация к размышлению была бы.


Мнение авторитетов — это информация как раз субъективная, а не объективная. Особенно когда ты сам выбираешь, каких авторитетов слушать, а каких нет.
Re[46]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.02.08 09:09
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


E>>А что, звание "С++ successor" автоматически подразумевает совместимость с C++?

E>>Sun в свое время Java рекламировал как "исправленный C++", тем не менее, об прозрачном интеропе с C++ ни тогда, ни сейчас речи не было.

AF>Занять нишу С++ у них и не получилось. Ни тогда, ни сейчас. Успех Явы произошел совсем не в той области, где ожидали ее разработчики.


Т.е. по вашему получается, что D планирует занять нишу C++ и чтобы у него это получилось, ему нужно иметь прозрачную интеграцию с C++? По другому никак?

А как же такой способ: то что написано на C++, останется на C++. Но новый софт будет разрабатываться на D и конкурировать с C++ным?
Например, в истории были случаи, когда С/C++ был вытеснен Eiffel-ем из "родной" для них ниши -- встроенного ПО.

E>>Вы хоть сами-то представляете во что это выльется?

E>>Если у меня C++ный класс возвращает ссылку на std::map с 30000 значений внутри, какая польза будет от маршалинга?

AF>А никто не говорит, что эти значения обязательно надо копировать. Сделать обертку, которая будет перенаправлять вызовы оригинальному объекту — не проблема. Во всяком случае, для автора компилятора, у которого все карты в руках.


Вы думаете, что перенаправление вызовов что-то решит? В D есть сборка мусора. Это означает другие подходы к разработке. Так, в D можно получить ссылку на элемент map-а и эта ссылка останется валидной даже в случае изъятия элемента из map-а. В С++ это не так. Поэтому, если в D будет создана обертка над C++ным map-ом, то придется считаться с проблемами, которых в D просто нет. Так зачем же их получать?

E>>Например, ссылки на высказывание авторитетных в этой области разработчиков. Например, если бы в каком-нибудь интервью об этом сказал Гослинг, Страуструп, Хёйсберг, Ксавье Лерой, Мартин Одерски Бертран Мейер или еще кто-нибудь из разработчиков языков программирования. Или какая-нибудь инсайдерская информация в блоге кого-нибудь из разработчиков C# или Java, или Scala, или Eiffel или OCaml о том, что "блин, забабахались мы с последним релизом языка, чуть живы остались, пора что-то в консерватории править". Тогда хоть какая-то объективная информация к размышлению была бы.


AF>Мнение авторитетов — это информация как раз субъективная, а не объективная. Особенно когда ты сам выбираешь, каких авторитетов слушать, а каких нет.


Не важно, что я выбираю. Когда авторитет говорит что-то об области, в которой он занимается, у меня есть основание полагать, что он обладает информацией и знаниями, которыми я не располагаю. Более того, есть возможность спросить у них об этом напрямую. И, что характерно, свои ответы они аргументируют. В отличии от.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[48]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.02.08 09:26
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


E>>Ну по этому показателю Nemerle до Eiffel-я еще расти и расти, и расти, и расти...

WH>Напомни когда там Eiffel появился...

В 1986. И умудрился прожить больше 20 лет, да и сейчас развивается.
Вот я и говорю -- поживет Nemerle столько же, сколько Eiffel уже прожил, тогда и можно будет какие-то выводы делать.

E>>Не-а, тестовых данных нет, проверять не на чем

WH>Если ты залогинен там есть такое маленькое окошечко куда ответ скормить можно...

Понял. Боюсь, что не найдется времени на такую забаву, а жаль ((

WH>В любом случае немерле сам по себе гораздо болие приятный язык нежели всякие там C#пы.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[51]: C++0x начали урезать
От: WolfHound  
Дата: 05.02.08 14:35
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Тогда как аргумент в пользу макросов это звучит малоубедительно.

Они как парашют... нужны редко но если нужны...

EC>Давай лучше так — если есть время глянь здесь и скажи позволят ли макросы как-то улучшить решение там описанное.

Потом посмотрю.

EC>Или можно ли на них реализовать это?

Можно.
Но для этого не нужно ни менять язык ни макросы.
Просто нужна библиотека.
        private GetStatuses () : void
        {
            def futures = daemonsStatusGetters_.Map(getter => //Запускаем асинхронные запросы в пуле и возвращаем список Future
            {
                def getStatus()
                {
                    def (daemonName, status) = getter();
                    (daemonName, status, DateTime.Now);
                }
                Futures.Future.Spawn(threadPool_, getStatus);
            });
            def results = futures.MapFiltered(result => // Проходимся по списку Futures и достаем результаты отфильтровывая неудачные запросы.
            {
                match (result.GetValueOrException())
                {
                | Futures.FutureValue.Value(result) =>
                    Some(result);
                | Futures.FutureValue.Exception =>
                    None();
                }
            });
            SpawnFutureInGUIContext(() => UpdateRows(results)).Wait(); // Запускаем обовление ГУИ и ждем завершение операции
        }

Все что для этого нужно это библиотека и нормальный вывод типов который понимает перегруженные генерик функции.
F# к таким языкам не относится... а немерле вполне...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[49]: C++0x начали урезать
От: WolfHound  
Дата: 05.02.08 14:35
Оценка:
Здравствуйте, eao197, Вы писали:

E>В 1986. И умудрился прожить больше 20 лет, да и сейчас развивается.

Да где он этот Eiffel? Кобол и фортран и то больше распространены...

E>Собственно, против этого я и не спорил (по крайней мере здесь ). Изначально я хотел узнать, почему это будущее есть только у языков, построенных по принципу Nemerle.

По тому что их:
1)Проще писать. Ибо писать нужно маленькое ядро. Остальное наворачивается простейшими макросами.
Болие
2)Проще на них писать. Ибо если вдруг в языке чегото не хватает это можно добавить макросом.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[47]: C++0x начали урезать
От: Andrei F.  
Дата: 05.02.08 14:41
Оценка:
Здравствуйте, eao197, Вы писали:

E>Т.е. по вашему получается, что D планирует занять нишу C++ и чтобы у него это получилось, ему нужно иметь прозрачную интеграцию с C++? По другому никак?


Нет, это не по моему так получается, это разработчик языка поставил перед собой такую задачу. И да, нормальный интероп с существующим кодом здесь необходим. В С++ был интероп с тем языком, для замены которого он был предназначен. В D такого интеропа не было. Сейчас что-то появилось, судя по ссылке которую дал FR, но до реальной применимости еще далековато.

E>Вы думаете, что перенаправление вызовов что-то решит? В D есть сборка мусора. Это означает другие подходы к разработке. Так, в D можно получить ссылку на элемент map-а и эта ссылка останется валидной даже в случае изъятия элемента из map-а. В С++ это не так. Поэтому, если в D будет создана обертка над C++ным map-ом, то придется считаться с проблемами, которых в D просто нет. Так зачем же их получать?


О да. Лучше вообще сделать вид, что решать задачу не нужно, и никаких проблем не будет.

E>Не важно, что я выбираю. Когда авторитет говорит что-то об области, в которой он занимается, у меня есть основание полагать, что он обладает информацией и знаниями, которыми я не располагаю. Более того, есть возможность спросить у них об этом напрямую. И, что характерно, свои ответы они аргументируют. В отличии от.


Главное, правильно выбрать подходящих авторитетов и проигнорировать остальных.
Re[50]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.02.08 14:43
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


E>>В 1986. И умудрился прожить больше 20 лет, да и сейчас развивается.

WH>Да где он этот Eiffel? Кобол и фортран и то больше распространены...

Ну аргументы классные, конечно. Если об Eiffel-е не кричат на каждом углу и он не считается мейнстримом, то это не значит, что его нет вообще. Живет себе потихоньку, за большие деньги продается, новые релизы два раза в год выпускают, ECMA стандарт не так давно был принят, сейчас EiffelStudio движется в сторону его полной реализации.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[48]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.02.08 14:47
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


E>>Т.е. по вашему получается, что D планирует занять нишу C++ и чтобы у него это получилось, ему нужно иметь прозрачную интеграцию с C++? По другому никак?


AF>Нет, это не по моему так получается, это разработчик языка поставил перед собой такую задачу.


А кстати, где именно Брайт поставил перед собой такую задачу? Где он декларировал, что D является непосредственной заменой C++?

AF>И да, нормальный интероп с существующим кодом здесь необходим. В С++ был интероп с тем языком, для замены которого он был предназначен.


Полного интеропа, кстати, все равно не было.

E>>Вы думаете, что перенаправление вызовов что-то решит? В D есть сборка мусора. Это означает другие подходы к разработке. Так, в D можно получить ссылку на элемент map-а и эта ссылка останется валидной даже в случае изъятия элемента из map-а. В С++ это не так. Поэтому, если в D будет создана обертка над C++ным map-ом, то придется считаться с проблемами, которых в D просто нет. Так зачем же их получать?


AF>О да. Лучше вообще сделать вид, что решать задачу не нужно, и никаких проблем не будет.


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

E>>Не важно, что я выбираю. Когда авторитет говорит что-то об области, в которой он занимается, у меня есть основание полагать, что он обладает информацией и знаниями, которыми я не располагаю. Более того, есть возможность спросить у них об этом напрямую. И, что характерно, свои ответы они аргументируют. В отличии от.


AF>Главное, правильно выбрать подходящих авторитетов и проигнорировать остальных.


Да я готов выслушать любого авторитета, вне зависимости от того, нравится он мне или нет. Вы ссылки-то дайте. Ну хоть что-то конкретное.

Пока за вас это Трурль делает.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[52]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.02.08 16:24
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


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

WH>В ситуации когда язык никому не нужен роме некоторых контор куда его проталкнули за откаты?

Попробуйте довести Nemerle хотя бы до такого состояния.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[38]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 05.02.08 20:16
Оценка:
Здравствуйте, Трурль, Вы писали:

E>>Я таки услышу ответ на вопрос о том, к пределу какой сложности приближается разработка современных языков программирования?

Т>

Я по секрету сознаюсь, что этот компилятор с Модулы уже на пределе допустимой сложности, и я бы чувствовал себя совершенно неспособным создать хороший компилятор для Ады.
Т>Н. Вирт

Здесь видимо уместно задать вопрос: какую сложность автор считает допустимой?
now playing: Autechre — fwzE
Re[49]: C++0x начали урезать
От: Andrei F.  
Дата: 06.02.08 05:52
Оценка:
Здравствуйте, eao197, Вы писали:

E>А кстати, где именно Брайт поставил перед собой такую задачу? Где он декларировал, что D является непосредственной заменой C++?


Читаю например результаты поиска в гугле и вижу в первой же ссылке:
Compiled, garbage collected, simpler C/C++ replacement

E>Полного интеропа, кстати, все равно не было.


Его было вполне достаточно, чтобы использовать старый код без переделки и написания оберток на каждую функцию.

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


Ну всё, опять начался бессмысленный поток сознания. А если я докажу что это не так, что будешь делать?
Re[50]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.02.08 07:15
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


E>>А кстати, где именно Брайт поставил перед собой такую задачу? Где он декларировал, что D является непосредственной заменой C++?


AF>Читаю например результаты поиска в гугле и вижу в первой же ссылке:

AF>Compiled, garbage collected, simpler C/C++ replacement

Ну вот, когда факты таки есть, вы способны их найти и предьявить.

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

E>>Полного интеропа, кстати, все равно не было.


AF>Его было вполне достаточно, чтобы использовать старый код без переделки и написания оберток на каждую функцию.


Но ведь и C был подмножеством C++, даже на уровне синтаксиса. И все равно совместимости 100% не было. Разве можно сказать, что C++ является подмножеством D?

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


AF>Ну всё, опять начался бессмысленный поток сознания. А если я докажу что это не так, что будешь делать?


Попробуйте сначала доказать. Я решаю проблемы по мере их поступления.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[51]: C++0x начали урезать
От: Andrei F.  
Дата: 06.02.08 07:41
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ну вот, когда факты таки есть, вы способны их найти и предьявить.

E>Значит, если вы никаких фактов в других случаях не приводите...

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

В данном случае актуальны варианты б) и в)

E>Но ведь и C был подмножеством C++, даже на уровне синтаксиса. И все равно совместимости 100% не было.


Есть большая разница между "совместимостью на 90%" и "совместимостью на 10%". Или ты ее тоже не видишь?

E>Попробуйте сначала доказать. Я решаю проблемы по мере их поступления.


Ну так вот, на сайте написано про "the limited ability described here to connect directly to C++ functions and classes.". Значит — число тех, кто считает эту фичу нужной, достаточно велико чтобы убедить разработчика. Ну так что?
Re[52]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.02.08 08:04
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


E>>Ну вот, когда факты таки есть, вы способны их найти и предьявить.

E>>Значит, если вы никаких фактов в других случаях не приводите...

AF>Ну, тут есть несколько вариантов

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

AF>В данном случае актуальны варианты б) и в)


Свое самомнение вы доказали с блеском.

E>>Но ведь и C был подмножеством C++, даже на уровне синтаксиса. И все равно совместимости 100% не было.


AF>Есть большая разница между "совместимостью на 90%" и "совместимостью на 10%". Или ты ее тоже не видишь?


Разница огромная, но даже при совместимости на 90% процентов (а между C и C++ она была больше), приходилось прилагать усилия для интеграции C-ного и C++ного кода.

E>>Попробуйте сначала доказать. Я решаю проблемы по мере их поступления.


AF>Ну так вот, на сайте написано про "the limited ability described here to connect directly to C++ functions and classes.". Значит — число тех, кто считает эту фичу нужной, достаточно велико чтобы убедить разработчика.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[53]: C++0x начали урезать
От: Andrei F.  
Дата: 06.02.08 08:20
Оценка:
Здравствуйте, eao197, Вы писали:

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


Раньше и просто интероп с С++ был объявлен невозможным. Потому что для этого необходим правильный name mangling, а это невозможно и вообще ненужно.

E>Свое самомнение вы доказали с блеском.


Нет, это просто результат исследования некоторых тем, где ты долго и упорно не мог понять разницу между динамической типизацией и выводом типов, или между текстовыми макросами и AST-макросами. У меня нет пары недель на то, чтобы чего-то тебе доказать, а самое главное — зачем?
Re[51]: C++0x начали урезать
От: Andrei F.  
Дата: 06.02.08 08:48
Оценка:
Здравствуйте, FR, Вы писали:

FR>Ты не там ищешь проблемы у D.

FR>Основная проблема в том что автор не может остановится. Перестать добавлять фичи и выпустить нормальный твердый релиз. Фич уже вполне достаточно.

Кстати, при наличии AST-макросов это не было бы проблемой. А вообще — согласен.
Re[52]: C++0x начали урезать
От: FR  
Дата: 06.02.08 08:55
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>Кстати, при наличии AST-макросов это не было бы проблемой. А вообще — согласен.


Если меняется ядро языка, или стандартные макросы то абсолютно такая же проблема.
Re[53]: C++0x начали урезать
От: Andrei F.  
Дата: 06.02.08 09:08
Оценка:
Здравствуйте, FR, Вы писали:

FR>Если меняется ядро языка, или стандартные макросы то абсолютно такая же проблема.


С трудом представляю, что можно менять в ядре, тем более — постоянно
Re[54]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.02.08 10:05
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


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


AF>Раньше и просто интероп с С++ был объявлен невозможным.


Раньше и шаблонов в D не было. И константности.
И история показывает, что Брайт зачатую принимает решения, от которых впоследствии сам же и отказывается. Нет никаких гарантий, что даже такая поддержка C++ не является очередным ошибочным шагом.

AF> Потому что для этого необходим правильный name mangling, а это невозможно и вообще ненужно.


Раньше я думал, что ваша настойчивость определяется только вашим упрямством. Но теперь видно, что это следствие элементарного незнания ни D, ни C++. Возможно, вам бы помогло изучение этих языков и обдумывание того, почему у MS с чистым C++ом в .NET ничего не получилось.

E>>Свое самомнение вы доказали с блеском.


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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[57]: C++0x начали урезать
От: WolfHound  
Дата: 06.02.08 13:17
Оценка:
Здравствуйте, FR, Вы писали:

FR>Даже я могу кучу вещей придумать в которых полные по тьюрингу макросы мало чем помогут, например добавь подержку продолжений ( http://en.wikipedia.org/wiki/Continuation ),

    public static MapFilteredLazy[T, U](this lst : list[T], fn : T -> option[U]) : SCG.IEnumerable[U]
    {
        def loop(_)
        {
        | head :: tail =>
            match (fn(head))
            {
            | Some(result) => yield result;
            | None => ();
            }
            loop(tail);
        | [] => ();
        }
        loop(lst);
    }


FR>или мультиметов в стиле CLOS,

Мультиметоды зло ибо их семантика слишком размыта.
Слишком много если...

FR>или нормальную ленивость,

Что значит нормальную?
Эта нормальная или нет http://nemerle.org/Lazy_evaluation

FR>думаю в этот список можно еще немало вещей добавить и со временем список будет только расти.

Попробуй.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: C++0x начали урезать
От: Aleksey Katorgin  
Дата: 06.02.08 13:39
Оценка:
Здравствуйте, remark, Вы писали:

R>>Хммм.... Похоже ты его боишься...

R>>Иначе почему вообще столько внимания и желания унизить такую "кривую" и "бесполезную" штуку?


R>Человек склонен бояться неизвестного



Хм... Сам пошутил, сам посмеялся.
Re[59]: C++0x начали урезать
От: WolfHound  
Дата: 06.02.08 14:11
Оценка:
Здравствуйте, FR, Вы писали:

FR>Угу тогда функторы аля STL это замыкания

FR>Сходи все таки по ссылке, посмотри как в схеме сделано.
И что я там должен увидить?
Запустить несколько раз можем? Можем.
Гденибудь сохранить и потом продолжить можем? Можем.
Что еще надо?

FR>То есть все что не можем сделать на макросах зло, понятно.


class A {}
class B : A {}
...
void fn(A, B)...
void fn(B, A)...
...
fn(new B(), new B());

Какую функцию вызывать будем?

Единственный нормальный способ множественной диспетчеризации это pattern matching по алгебраическим типам.

FR>Сравнивай с хаскелем или клейном.

И? Там нужно постоянно везде расставлять строгость иначе все тормозит и стек заканчивается...
Ленивость нужна там где она нужна и нигде более.

FR>А зачем, ты скажешь или не нужно или приведешь частично коряво сделаную реализацию и скажешь что этого достаточно. Это все равно что обчитавшемуся Александреску говорить что boost::lambda корявое убожество.

Слив засчитан.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[60]: C++0x начали урезать
От: FR  
Дата: 06.02.08 14:21
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>И что я там должен увидить?


Ты? Ничего.

WH>Запустить несколько раз можем? Можем.

WH>Гденибудь сохранить и потом продолжить можем? Можем.
WH>Что еще надо?

Ничего ни нужно. Бесполезно, просто нужно чтобы прошло какое-то время и новая игрушка тебе наскучила, тогда можно будет нормально разговаривать. Хотя желания общатся с тобой у меня с каждым разом становится намного меньше. Сейчас разговор точно не получится, пока.
Re[61]: C++0x начали урезать
От: WolfHound  
Дата: 06.02.08 14:29
Оценка:
Здравствуйте, FR, Вы писали:

FR>Ничего ни нужно. Бесполезно, просто нужно чтобы прошло какое-то время и новая игрушка тебе наскучила, тогда можно будет нормально разговаривать. Хотя желания общатся с тобой у меня с каждым разом становится намного меньше. Сейчас разговор точно не получится, пока.

Как всегда... одни эмоции и никаких аргументов.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[63]: C++0x начали урезать
От: WolfHound  
Дата: 06.02.08 15:11
Оценка:
Здравствуйте, FR, Вы писали:

FR>Аргументы я тебе привел в виде трех примеров которые на макросах Немерли полноценно не реализуются, ты же мне в ответ приводишь пример в котором совершено не используются макросы и который показывает использование механизма который является частным очень ограниченым случаем того что я просил.

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

FR>На второй вопрос отвечаешь что это не нужно.

А я вобщето аргументировал... какой метод то вызывать?
Ась?

FR>На третий опять приводишь частный случай. Нормально.

Выполнение по требованию есть?
Меморизация есть?
А строгое ваполнение по умолчанию это даже хорошо.
Ибо хоскель из-за своей лени жуткий тормоз... и стек у него иногда заканчивается.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[64]: C++0x начали урезать
От: VoidEx  
Дата: 06.02.08 15:24
Оценка:
Здравствуйте, WolfHound, Вы писали:

Я, конечно, могу ошибаться, но Ваши ответы очень смахивают на ответы:
1. Когда пытаешься рассказать Дельфистам, что такое шаблоны.
2. Когда пытаешься рассказать приверженцам C++/C#/Delphi/..., что такое функции как first class objects.
3. Многое другое

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

П.С. Моё личное мнение, можно мне не отвечать.
Re[64]: C++0x начали урезать
От: FR  
Дата: 06.02.08 15:41
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А чего тебе не хватает?

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

Продолжения я пока вкуриваю, но уже вижу что они гораздо мощнее чем yield. Пока я в них как и ты Блаб

FR>>На второй вопрос отвечаешь что это не нужно.

WH>А я вобщето аргументировал... какой метод то вызывать?
WH>Ась?

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

FR>>На третий опять приводишь частный случай. Нормально.

WH>Выполнение по требованию есть?
WH>Меморизация есть?

Настоящей тотальной ленивости нет, этого как и продолжений макросами не сделать.
Re[65]: C++0x начали урезать
От: WolfHound  
Дата: 06.02.08 15:59
Оценка:
Здравствуйте, FR, Вы писали:

FR>Продолжения я пока вкуриваю, но уже вижу что они гораздо мощнее чем yield. Пока я в них как и ты Блаб

Да чем мощьнее то?

FR>Ты перевел разговор с возможности их реализации на макросах на другую тему.

FR>Там ничего нельзя вызвать, будет в зависимости от реализации или ошибка компиляции или исключение, или даже тихое ничегониделание,
Все будет выглядеть както так
class Test
{
    [MultyMethodHost]
    public static MMethod([MultyMethodThis] a1 : A, [MultyMethodThis]a2 : A) : void;
}
class Test2
{
    [MultyMethod]
    public static MMethod([MultyMethodThis] a1 : B, [MultyMethodThis]a2 : A) : void
    {
        ...
    }
}

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

FR>все точно также как в патерн матчинге если прилетело то что не обрабатывается.

Не точно. Все паттерны заданны на этапе компиляции и определен их порядок.
Благодоря этому можно проверить что все паттрены доступны и покрываются все варианты входных значений.

FR>Настоящей тотальной ленивости нет,

Она там не тотальна... там можно указывать компилятору что вычисления нужно проводить строго.
Болие того этим не редко занимаются ибо иначе будут тормоза и вылеты.
Давай еще гарантированное отсутствие _|_ требовать... Правда в этом случае ты вобще ничего кроме простеньких примеров написать не сможешь...

FR>этого как и продолжений макросами не сделать.

Ты скажи чего тебе в yield не хватает.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[66]: C++0x начали урезать
От: FR  
Дата: 06.02.08 16:29
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


FR>>Продолжения я пока вкуриваю, но уже вижу что они гораздо мощнее чем yield. Пока я в них как и ты Блаб

WH>Да чем мощьнее то?

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

WH>Все будет выглядеть както так


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

WH>
WH>class Test
WH>{
WH>    [MultyMethodHost]
WH>    public static MMethod([MultyMethodThis] a1 : A, [MultyMethodThis]a2 : A) : void;
WH>}
WH>class Test2
WH>{
WH>    [MultyMethod]
WH>    public static MMethod([MultyMethodThis] a1 : B, [MultyMethodThis]a2 : A) : void
WH>    {
WH>        ...
WH>    }
WH>}
WH>

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

Так я тебе уже писал.

FR>>все точно также как в патерн матчинге если прилетело то что не обрабатывается.

WH>Не точно. Все паттерны заданны на этапе компиляции и определен их порядок.

Здесь также, порядок тоже можно сделать естественный по мере объвления.

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


Ну бывают и полиморфные варианты и их паттерн матчинг, там точно такие же проблемы.
Кстати немерле подерживает полиморфные варианты? И если нет (или бы не подерживал) то можно их прикрутить макросами?

FR>>Настоящей тотальной ленивости нет,

WH>Она там не тотальна... там можно указывать компилятору что вычисления нужно проводить строго.

Тотальна, поэтому чтобы убрать нужно явно указывать.

WH>Болие того этим не редко занимаются ибо иначе будут тормоза и вылеты.

WH>Давай еще гарантированное отсутствие _|_ требовать... Правда в этом случае ты вобще ничего кроме простеньких примеров написать не сможешь...

FR>>этого как и продолжений макросами не сделать.

WH>Ты скажи чего тебе в yield не хватает.

Мне сейчас все хватает, я же Блаб в продолжениях
Re[59]: C++0x начали урезать
От: WolfHound  
Дата: 06.02.08 17:24
Оценка:
Здравствуйте, lomeo, Вы писали:

L>continuations — это call/cc. Нарисуй его, пожалуйста. Как решить частные случаи, которые решает call/cc, не особо интересно. Вопрос был о поддержке продолжений.

Покажи случай который не делается через yield. Тебе это должно быть не трудно.

L>Мультиметоды — зло, хотя бы по той причине, что их нет в Немерле

Я уже сказал чем плохи мультиметоды.
Если ты скажешь как разрешить их противоречия я их без проблем сделаю.

L>На самом деле тут о чём разговор? О том, что если макросы есть, то всё — можно уже не расширять язык или что?

По большей части да. По крайней мере в той что любит крутиться Aлександреску.
Что касается всего остального то тут больше вопросов чем ответов.
Например ленивость по умолчанию мягко говоря сомнительна.
Хотя при жилании можно сделать и болие общую ленивость что уже сделана вопрос лишь в том, а оно надо?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[67]: C++0x начали урезать
От: WolfHound  
Дата: 06.02.08 17:24
Оценка:
Здравствуйте, FR, Вы писали:

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

А вот с этого места давай подробнее... ибо у нас есть изменяемые переменные... как ты их откатывать будешь?
А еще есть IO...

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

Ты в самом деле думаешь что я буду делать сомнительную хреновину с неясной семантикой?

FR>Здесь также, порядок тоже можно сделать естественный по мере объвления.

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

FR>Ну бывают и полиморфные варианты и их паттерн матчинг, там точно такие же проблемы.

Так их нормальные люди не используют.

FR>Кстати немерле подерживает полиморфные варианты?

Да.
public class A {}
public class B : A {}

    public static MMethod(_ : A, _ : A) : string
    {
    | (_a1 is B, _a2 is B) => "B, B"
    | (_a1 is B, _a2 is A) => "B, A"
    | (_a1 is A, _a2 is B) => "A, B"
    | (_a1 is A, _a2 is A) => "A, A"
    }

FR>И если нет (или бы не подерживал) то можно их прикрутить макросами?
http://nemerle.org/Quick_Guide#Regular_Expressions_match
regexp макрос.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[68]: C++0x начали урезать
От: FR  
Дата: 06.02.08 17:41
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


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

WH>А вот с этого места давай подробнее... ибо у нас есть изменяемые переменные... как ты их откатывать будешь?

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

WH>А еще есть IO...


С этим да могут быть фокусы.

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

WH>Ты в самом деле думаешь что я буду делать сомнительную хреновину с неясной семантикой?

Я еще ни разу в таких спорах от тебя никакого компилируемого кода не видел (кроме отсылки к примерам немерле)

FR>>Здесь также, порядок тоже можно сделать естественный по мере объвления.

WH>Те методы нужно объявить в одном классе? В рантайме нельзя подключать новые методы?

Зачем, пусть в разных пусть будут свободные функции. Надеюсь в NET как и в питоне доступна информация об очередности их объвления, так что тут проблем не вижу.

WH>Так чем это отличается от того что уже есть?

WH>Тем что это выглядит как разные функции не в счет.

FR>>Ну бывают и полиморфные варианты и их паттерн матчинг, там точно такие же проблемы.

WH>Так их нормальные люди не используют.

Опять то что я не использую не нужно?

FR>>И если нет (или бы не подерживал) то можно их прикрутить макросами?

WH>http://nemerle.org/Quick_Guide#Regular_Expressions_match
WH>regexp макрос.

Хорошо, значит расширяемость паттерн матчинга авторы предусмотрели, а если бы нет? Если бы его вообще не было в языке легко ли было бы реализовать на макросах?
Re[69]: C++0x начали урезать
От: WolfHound  
Дата: 06.02.08 18:21
Оценка:
Здравствуйте, FR, Вы писали:

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

А памяти хватит? А ты уверен? А что делать с многопоточностью?

FR>Я еще ни разу в таких спорах от тебя никакого компилируемого кода не видел (кроме отсылки к примерам немерле)

Это просто не правда.

FR>Зачем, пусть в разных пусть будут свободные функции. Надеюсь в NET как и в питоне доступна информация об очередности их объвления, так что тут проблем не вижу.

1).NET не поддерживает свободные функции
2)Порядок парсинга различных файлов не определен.

FR>Опять то что я не использую не нужно?

А зачем? Это же по сути приведение базового класса к потомку.
Единственное место где оно нужно это IOC контейнер.
Все остальное жесточайшая кривь.

FR>Хорошо, значит расширяемость паттерн матчинга авторы предусмотрели, а если бы нет?

А ты знаешь как этот макрос работает?
Ведь нет.
Так вот там от match ничего не остается...
  macro @regexp (mat)
  syntax ("regexp", mat) 
  {
    /// syntax is [regexp match { .. }], so [mat] must be [match]
    match (mat) {
      | <[ match ($val) { ..$cases } ]> => // Собственно на этом жизнь match'а и заканчивается...
      ...
      | _ =>
        Message.FatalError ("the `regexp' macro expects a match construct")
    }
  }

Так что и без него можно былобы все сделать.

FR>Если бы его вообще не было в языке легко ли было бы реализовать на макросах?

В немерле полные по Тьюрингу имеющие доступ ко всему API компилятора макросы.
Те при особом жилании на них можно сделать практически все. Единственное что необходимо соблюдать парность скобок.
Другое дело что на практике нужно лишь изредка догенерить некоторые методы по шаблону или что-то типа этого.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[70]: C++0x начали урезать
От: FR  
Дата: 06.02.08 18:57
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


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

WH>А памяти хватит? А ты уверен? А что делать с многопоточностью?

Если нормально реализовать памяти хватит.
С многопоточностью не знаю, пока не дошел, надо спросить тех кто лучше разбирается.

FR>>Я еще ни разу в таких спорах от тебя никакого компилируемого кода не видел (кроме отсылки к примерам немерле)

WH>Это просто не правда.

Может быть, у меня давний склероз

FR>>Зачем, пусть в разных пусть будут свободные функции. Надеюсь в NET как и в питоне доступна информация об очередности их объвления, так что тут проблем не вижу.

WH>1).NET не поддерживает свободные функции
WH>2)Порядок парсинга различных файлов не определен.

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

FR>>Опять то что я не использую не нужно?

WH>А зачем? Это же по сути приведение базового класса к потомку.
WH>Единственное место где оно нужно это IOC контейнер.
WH>Все остальное жесточайшая кривь.

То есть весь эрланг например "жесточайшая кривь" ?

WH>Так что и без него можно былобы все сделать.


Хорошо в этом случае Немерли на высоте.

FR>>Если бы его вообще не было в языке легко ли было бы реализовать на макросах?

WH>В немерле полные по Тьюрингу имеющие доступ ко всему API компилятора макросы.
WH>Те при особом жилании на них можно сделать практически все. Единственное что необходимо соблюдать парность скобок.

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

WH>Другое дело что на практике нужно лишь изредка догенерить некоторые методы по шаблону или что-то типа этого.


Тут лучше не зарекатся
Re[71]: C++0x начали урезать
От: WolfHound  
Дата: 06.02.08 19:25
Оценка:
Здравствуйте, FR, Вы писали:

FR>Если нормально реализовать памяти хватит.

Ну-ну.
FR>С многопоточностью не знаю, пока не дошел, надо спросить тех кто лучше разбирается.
Там вобще все весело будет.

FR>Значит для NET придется вводить параметр указывающий порядок, или всемогущие макросы как-то помогут?

Тут ничто не поможет.
Если порядок парсинга файлов не определен то он неопределен и ничего ты тут не сделаешь.
Внутри одного файла порядок получить можно но толку то?
Да и зачем если:
1)Фича мягко говоря сомнительная
2)pattern matching это все умеет. Еще и предупреждения выдаст если один образец другой скрывает.

FR>То есть весь эрланг например "жесточайшая кривь" ?

Все языки с динамической типизацией жесточайшая кривь.
Имею Мнение Хрен Оспоришь что приведение типа в рантайме допустимо лишь при получении сервиса из IOC контейнера (и то только по тому что я пока не придумал как выкрутиться в этом случае).

FR>Хорошо в этом случае Немерли на высоте.

Он на высоте в гораздо болие большом колличестве случаев чем ты думаешь.

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


В D тебе придется повторить компилятор D.
В немерле нет.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[58]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 06.02.08 20:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>
WH>    public static MapFilteredLazy[T, U](this lst : list[T], fn : T -> option[U]) : SCG.IEnumerable[U]
WH>    {
WH>        def loop(_)
WH>        {
WH>        | head :: tail =>
WH>            match (fn(head))
WH>            {
WH>            | Some(result) => yield result;
WH>            | None => ();
WH>            }
WH>            loop(tail);
WH>        | [] => ();
WH>        }
WH>        loop(lst);
WH>    }
WH>

Эта штука макросами реализована? Я про yield.
now playing: Autechre — Simmm
Re[69]: C++0x начали урезать
От: WolfHound  
Дата: 06.02.08 20:42
Оценка:
Здравствуйте, EvilChild, Вы писали:

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

Вот и я о томже... что-то FR путает...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[59]: C++0x начали урезать
От: WolfHound  
Дата: 06.02.08 20:42
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Эта штука макросами реализована? Я про yield.

Конкретно эта нет.
Но если пойти на необходимость вешать макрос на метод то можно и макросами
    [YieldSupport]
    public static MapFilteredLazy[T, U](this lst : list[T], fn : T -> option[U]) : SCG.IEnumerable[U]
    ...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[52]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 06.02.08 20:43
Оценка:
Здравствуйте, lomeo, Вы писали:

WH>>>Коротко нельзя да и НДА.

EC>>Тогда как аргумент в пользу макросов это звучит малоубедительно.

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


L>Иногда подобные ситуации связаны с ограничениями в языке. Поскольку я работаю на Яве, то могу много про это рассказать В C# с этим получше, но не замечательно. Вообще, ИМХО, чем больше в языке конструкций являются first-class citizen, тем лучше — нет ограничений на их применение. Если же ограничения есть, то приходится для двух схожих задач, отличных только по этим ограничениям применять два схожих куска кода вместо одного. Эту дыру можно прикрыть кодогенерацией или макросами (на них можно смотреть, как на один из способов кодогенерации).


Я примерно представляю для чего они нужны, но было сказано, что возникла реальная необходимость,
и как только захотелось узнать подробности — так сразу НДА и прочие отмазки.
Вот если бы LINQ приделали на макросах это был бы убийственный аргумент.
now playing: Autechre — Simmm
Re[60]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 06.02.08 20:47
Оценка:
Здравствуйте, WolfHound, Вы писали:

EC>>Эта штука макросами реализована? Я про yield.

WH>Конкретно эта нет.
WH>Но если пойти на необходимость вешать макрос на метод то можно и макросами
WH>
WH>    [YieldSupport]
WH>    public static MapFilteredLazy[T, U](this lst : list[T], fn : T -> option[U]) : SCG.IEnumerable[U]
WH>    ...
WH>

Можешь пояснить, что этот код делает? То же, что и ранееприведённый? Зачем атрибут [YieldSupport] установлен?
И почему yield не макросом сделан?
now playing: Duoteque — Drug Queen
Re[61]: C++0x начали урезать
От: WolfHound  
Дата: 06.02.08 21:14
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Можешь пояснить, что этот код делает? То же, что и ранееприведённый?

Угу.
EC>Зачем атрибут [YieldSupport] установлен?
Это макрос.
EC>И почему yield не макросом сделан?
Я еще не слишком глубоко компилятор копал.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[55]: C++0x начали урезать
От: Andrei F.  
Дата: 07.02.08 04:19
Оценка:
Здравствуйте, eao197, Вы писали:

E>И история показывает, что Брайт зачатую принимает решения, от которых впоследствии сам же и отказывается. Нет никаких гарантий, что даже такая поддержка C++ не является очередным ошибочным шагом.


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

E>Раньше я думал, что ваша настойчивость определяется только вашим упрямством. Но теперь видно, что это следствие элементарного незнания ни D, ни C++.


Я абсолютно уверен, что есть немало людей, которые знают С++ лучше меня. Но я еще больше уверен, что ты в их число не входишь и вряд ли когда-нибудь будешь.
Что касается D, то я знаю о нем вполне достаточно, чтобы не хотеть узнавать больше.

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




E>Польщен тем, что мои высказывания стали следствием исследования.


Мне интересно читать темы о Немерле. А не заметить там такой объемистый и невежественный вклад было просто невозможно.

E>Однако, если бы вы читали то, что я пишу здесь, то могли бы увидеть, что я разговариваю с вами на "Вы" и был бы признателен, если бы вы поступали так же.


Если есть желание поупражняться в формально-канцелярском стиле речи — ради бога. Но это надо хотя бы делать грамотно. "Вы" при обращении к одному лицу всегда пишется с большой буквы.
Re[72]: C++0x начали урезать
От: FR  
Дата: 07.02.08 04:39
Оценка:
Здравствуйте, WolfHound, Вы писали:

В общем извини, дальше беседовать с тобой мне не интересно, и работать надо, и пришло опять к тому о чем я сразу и подумал, к разбрызгиванию соплей. Хотя было-бы инетересно конечно нормально поговорить от том что могут макросы а чего нет.
Re[56]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.02.08 07:06
Оценка:
Здравствуйте, Andrei F., Вы писали:

E>>Раньше я думал, что ваша настойчивость определяется только вашим упрямством. Но теперь видно, что это следствие элементарного незнания ни D, ни C++.


AF>Я абсолютно уверен, что есть немало людей, которые знают С++ лучше меня. Но я еще больше уверен, что ты в их число не входишь и вряд ли когда-нибудь будешь.


Аминь!

AF>Что касается D, то я знаю о нем вполне достаточно, чтобы не хотеть узнавать больше.


Тем не менее, этих явно поверхносных знаний оказывается достаточно, чтобы утверждать, что между D и C++ возможна прозрачная интероперабильность, да еще с учетом шаблонов, множественного наследования, различных объектных моделей, разных систем поддержки исключений и сборки мусора?

Показательно однако.

E>>Польщен тем, что мои высказывания стали следствием исследования.


AF>Мне интересно читать темы о Немерле. А не заметить там такой объемистый и невежественный вклад было просто невозможно.


Значит, у меня получилось!!!
В свое время апологеты Nemerle спасибо мне говорили за то, что я поддерживаю интерес к этому языку у читателей форума. Видимо, не зря говорили.

E>>Однако, если бы вы читали то, что я пишу здесь, то могли бы увидеть, что я разговариваю с вами на "Вы" и был бы признателен, если бы вы поступали так же.


AF>Если есть желание поупражняться в формально-канцелярском стиле речи — ради бога. Но это надо хотя бы делать грамотно. "Вы" при обращении к одному лицу всегда пишется с большой буквы.


На счет "всегда" вы опять горячитесь. Несложный поиск по Интернету приводит к простому выводу:
здесь

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


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

Да и для пояснения: когда я написал "Вы", то это означало всего лишь привлечение внимания к тому факту, что мы с вами используем разные способы обращения к собеседнику.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[54]: C++0x начали урезать
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 07.02.08 10:21
Оценка:
Здравствуйте, WolfHound, Вы писали:

EC>>Я примерно представляю для чего они нужны, но было сказано, что возникла реальная необходимость, и как только захотелось узнать подробности — так сразу НДА и прочие отмазки.

WH>Так эта... см код компилятора там их полно... например SupportRelocation

Кстати, этот SupportRecolation (если это то, о чём я думаю) — уже обсуждался. Насколько я помню, там показывалось, что на некоторых языках это можно красиво сделать без макросов. И то, что здесь он был сделан на макросах, может говорить о некоторых недостатках (ну или по крайней мере отсутствии некоторых фич) в языке.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[55]: C++0x начали урезать
От: WolfHound  
Дата: 07.02.08 13:50
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Кстати, этот SupportRecolation (если это то, о чём я думаю) — уже обсуждался. Насколько я помню, там показывалось, что на некоторых языках это можно красиво сделать без макросов. И то, что здесь он был сделан на макросах, может говорить о некоторых недостатках (ну или по крайней мере отсутствии некоторых фич) в языке.

Где?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[55]: C++0x начали урезать
От: WolfHound  
Дата: 07.02.08 13:50
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Ну уж? Не надо лукавить. Я даже переписку читал, где авторам языка предлагали добавить новый тип макросов специально для того, чтоб можно было реализовать тот же LINQ.

Там разговор шол о том чтобы сделать идентичный синтакс. А оно надо идентичный?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[61]: C++0x начали урезать
От: WolfHound  
Дата: 07.02.08 13:50
Оценка:
Здравствуйте, lomeo, Вы писали:

L>1. Сам примитив call/cc. Я хочу, чтобы мои вычисления не знали о том, что они используются как продолжения.

L>В принципе, если yield является first-class order, то этого должно быть достаточно.
Функция в который использован yield превращается в генератор последовательности.

L>2. Классический оператор amb. В частности, пример с (if (amb #t #f) 1 (amb)) в котором amb обязан возвращать #t.

А по русски можно?

L>4. shift/reset примитивы

Это что?

L>5. То, что вытворяет Олег Киселёв даже просить не буду

А что он вытворяет?

L>Как аргумент того, что язык есть куда расширять это может и не покатит — может эти продолжения нафиг не сдались пользователям Немерле, а может предложение рождает спрос — хз. Но вот то, что не всё сделаешь на макросах, по крайней мере, с практической точки зрения — вполне покатит.

С практической точки зрения былобы жилание.

L>Про ленивость по умолчанию вроде как никто не говорил — это вообще вопрос выбора, спорить тут не о чем.

FR говорил.
L>Прочее — это, по моему, отголоски дискуссии о том, что макросы — это индикаторы недоделок в языке. Так что на макросы можно смотреть и с другой стороны — если макросы есть, значит есть что расширять
Угу... паскаль совершенство...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[73]: C++0x начали урезать
От: WolfHound  
Дата: 07.02.08 13:50
Оценка:
Здравствуйте, FR, Вы писали:

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

Зеркало принести?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[57]: C++0x начали урезать
От: Andrei F.  
Дата: 07.02.08 14:26
Оценка:
Здравствуйте, eao197, Вы писали:

E>Тем не менее, этих явно поверхносных знаний оказывается достаточно, чтобы утверждать, что между D и C++ возможна прозрачная интероперабильность, да еще с учетом шаблонов, множественного наследования, различных объектных моделей, разных систем поддержки исключений и сборки мусора?


И снова бинарное мышление. Или всё, или ничего.
Кстати, это оказывается довольно распространенное явление, которое называется "патологический перфекционизм".

E>Значит, у меня получилось!!!

E>В свое время апологеты Nemerle спасибо мне говорили за то, что я поддерживаю интерес к этому языку у читателей форума. Видимо, не зря говорили.

Так вот в чем дело! Буду знать

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


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

E>Да и для пояснения: когда я написал "Вы", то это означало всего лишь привлечение внимания к тому факту, что мы с вами используем разные способы обращения к собеседнику.


Предлагаю не разводить неуместный официоз и обращаться на "ты"
Re[62]: C++0x начали урезать
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 07.02.08 14:36
Оценка:
Здравствуйте, WolfHound, Вы писали:

L>>1. Сам примитив call/cc. Я хочу, чтобы мои вычисления не знали о том, что они используются как продолжения.

L>>В принципе, если yield является first-class order, то этого должно быть достаточно.
WH>Функция в который использован yield превращается в генератор последовательности.

Т.е. можно так (я просто не знаю)?

Yield[T](value: T): T
{
    yield value;
}

Foo[T](fn: T -> T)...
{
    ...fn(T);
}

Foo(Yield)


За синтаксис прошу прощения, не знаю языка.

L>>2. Классический оператор amb. В частности, пример с (if (amb #t #f) 1 (amb)) в котором amb обязан возвращать #t.

WH>А по русски можно?

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

Примеры:

(amb) — ошибка (нечего возвращать)

(amb 1 2 3 (amb) 4 (amb)) — вернёт 1, 2, 3 или 4

(if (eq? 3 (amb 1 2 3 4 5))
1
(amb)) — первый amb обязательно вернёт 3, иначе будет ошибка в программе (второй amb).

L>>4. shift/reset примитивы

WH>Это что?

palm_mute очень интересно про них рассказывал здесь:
http://palm-mute.livejournal.com/12291.html

L>>5. То, что вытворяет Олег Киселёв даже просить не буду

WH>А что он вытворяет?

http://okmij.org/ftp/Computation/Continuations.html
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[56]: C++0x начали урезать
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 07.02.08 14:44
Оценка:
Здравствуйте, WolfHound, Вы писали:

L>>Кстати, этот SupportRecolation (если это то, о чём я думаю) — уже обсуждался. Насколько я помню, там показывалось, что на некоторых языках это можно красиво сделать без макросов. И то, что здесь он был сделан на макросах, может говорить о некоторых недостатках (ну или по крайней мере отсутствии некоторых фич) в языке.


WH>Где?


По моему где то здесь, в философии. Тема называлась "Являются ли макросы свидетельством..."

Там Generics из Хаскеля предлагалось, как возможное решение без макросов.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[56]: C++0x начали урезать
От: VoidEx  
Дата: 07.02.08 15:03
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Там разговор шол о том чтобы сделать идентичный синтакс. А оно надо идентичный?


Ну!
Re[39]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 15:53
Оценка:
Здравствуйте, FR, Вы писали:

FR>Объем знаний чтобы хорошо программировать и проектировать в русле ФП никак ни меньше такового для ООП. Скорее даже больше.


Обоснуй. Лично я с этим утверждение не согласен.

FR>Я вот не могу сказать что освоил ФП, локально да, применяю легко, а вот проектирование и решения в духе парадигмы со скрипом.


Нет в ФП никаких специальных средств проектирования. ФП это развитие идей структурного программирования. "Сахар", можно сказать (чур меня ).

VD>>2. В том то и дело, что если знать Шарп (а таких программистов очень много), то фунциональные вещи осваиваются довольно легко и, что не маловажно, прямо во время работы над каким-нибудь проектом. Желательно только чтобы при этом рядом с новичком работал кто-то кто уже прошел этот пукть и может потихоничку направлять новичка в нужное русло.


FR>Угу только по моему в резулmтате получаются больше "пользователи сахара"


Если переведешь это предожение на Русский, то можно будет осбудить его.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 15:53
Оценка:
Здравствуйте, eao197, Вы писали:

AF>>Если учесть размер команды, то при разработке на языке без макросов никаких контрактов не было бы вообще.


E>В Sign# есть, в D есть, в Nice есть такие же контракты. И команды там были не на много больше, чем у Nemerle.


Sign# — это язык созданный ради этих самых контрактов. Там взят готовый компилятор МС и добавлены контракты.
У D есть автор пашуший на фул-тайм и при этом сделавший язык уступающий Немерлу почти во всем. Кстати, Немерле поддерживает два вида контрактов. Первый как в Ди проверяется в рантайме, а торой как в Sign# по возможности проверяется во время компиляции. Так что и здесь Ди лузер.

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


А зачем? Такого никто не утверждал. Но то что это полезные вещи даже ты наверно не возьмешся опровергать. Не так ли?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[42]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.02.08 16:05
Оценка:
Здравствуйте, VladD2, Вы писали:

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


AF>>>Если учесть размер команды, то при разработке на языке без макросов никаких контрактов не было бы вообще.


E>>В Sign# есть, в D есть, в Nice есть такие же контракты. И команды там были не на много больше, чем у Nemerle.


VD>Sign# — это язык созданный ради этих самых контрактов. Там взят готовый компилятор МС и добавлены контракты.

VD>У D есть автор пашуший на фул-тайм и при этом сделавший язык уступающий Немерлу почти во всем. Кстати, Немерле поддерживает два вида контрактов. Первый как в Ди проверяется в рантайме, а торой как в Sign# по возможности проверяется во время компиляции. Так что и здесь Ди лузер.

Смысла этой сентенции не уловил, тем более, что для проверки контрактов Spec# использует сторонний инструмент, реализованный другой компанией на Java.

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


VD>А зачем? Такого никто не утверждал.


Никто?

А настоящее будущее — за Немерле или другими языками, которые будут устроены по тому же принципу.

Хотя потом выяснилось, что это было даже не утверждение, а частное мнение.

VD>Но то что это полезные вещи даже ты наверно не возьмешся опровергать. Не так ли?


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[58]: C++0x начали урезать
От: VoidEx  
Дата: 07.02.08 16:48
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>Даже я могу кучу вещей придумать в которых полные по тьюрингу макросы мало чем помогут, например добавь подержку продолжений ( http://en.wikipedia.org/wiki/Continuation ), или мультиметов в стиле CLOS, или нормальную ленивость, думаю в этот список можно еще немало вещей добавить и со временем список будет только расти.


VD>Все это реализуется (если уже не реализовано) на макросах. Так что просто кончай сотрясать воздух.


И как, позвольте поинтересоваться, amb реализуется на макросах?
А еще хочется узнать, как реализуется на макросах LINQ.
Re[62]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 07.02.08 17:20
Оценка:
Здравствуйте, WolfHound, Вы писали:

EC>>Можешь пояснить, что этот код делает? То же, что и ранееприведённый?

WH>Угу.
В общем yield ниразу не макрос, тогда к чему ты привёл код с yield как обоснование их нужности?
То что yield это не continuuation я так понимаю даже и упоминать бесполезно.
now playing: Duoteque — Electronischze
Re[74]: C++0x начали урезать
От: FR  
Дата: 07.02.08 17:30
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

WH>Зеркало принести?

Не поможет
Жаль у меня по работе завал, так что флеймить некогда.
В общем останемся при своих
Re[40]: C++0x начали урезать
От: FR  
Дата: 07.02.08 17:48
Оценка:
Здравствуйте, VladD2, Вы писали:

FR>>Объем знаний чтобы хорошо программировать и проектировать в русле ФП никак ни меньше такового для ООП. Скорее даже больше.


VD>Обоснуй. Лично я с этим утверждение не согласен.


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

FR>>Я вот не могу сказать что освоил ФП, локально да, применяю легко, а вот проектирование и решения в духе парадигмы со скрипом.


VD>Нет в ФП никаких специальных средств проектирования. ФП это развитие идей структурного программирования. "Сахар", можно сказать (чур меня ).


Gaperton со своей Problem K очень наглядно показал что есть.
Мне кажется ты просто не докурил ФП.
Я вот тихонько докуриваю но идет туго

FR>>Угу только по моему в резулmтате получаются больше "пользователи сахара"


VD>Если переведешь это предожение на Русский, то можно будет осбудить его.


Очень просто, используются фичи (практически только локальные) из ФП помогающие делать код короче, при этом все, часто даже то, что легко и красиво можно сделать функционально, пишется в смешаном функционально-императивном стиле. Функциональная декомпозиция вообще не применяется. Я не говорю что это одназначно плохо.
Re[59]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:13
Оценка:
Здравствуйте, FR, Вы писали:

FR>Угу тогда функторы аля STL это замыкания

FR>Сходи все таки по ссылке, посмотри как в схеме сделано.

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

FR>>>или мультиметов в стиле CLOS,

WH>>Мультиметоды зло ибо их семантика слишком размыта.
WH>>Слишком много если...

FR>То есть все что не можем сделать на макросах зло, понятно.


В том то идело, что можно. Только не нужно. О том как реализовать мультиметоды была тема в немерловой конфе. Автор вопроса согласился с камилом, что на макросах все прекрасно реализуюется. Просто учитывая, что есть паттерн-матчинг решающий проблему множественной динамической димпетчиризации, особой необходимости именно в мультиметодах нет. По существу мультиметоды и есть только в КЛОС-е который является макробиблиотекой для ЛИСП-а в котором оных нет. И есть они в КЛОС-е в не малой мере потому, что в ЛИСП-е нет паттерн-матчинга (а потребность в мультидиспатче есть).

Так что не гони.

FR>>>или нормальную ленивость,

WH>>Что значит нормальную?
WH>>Эта нормальная или нет http://nemerle.org/Lazy_evaluation

FR>Сравнивай с хаскелем или клейном.


Сравнивл. Разницы не обнаружил. Просто другие умолчания. В нем по умолчанию все лениво, а в Немерле нет. Вот тормозит Хаскель по черному (чтобы его фанаты не говорили) — это да.

FR>>>думаю в этот список можно еще немало вещей добавить и со временем список будет только расти.

WH>>Попробуй.

FR>А зачем, ты скажешь или не нужно или приведешь частично коряво сделаную реализацию и скажешь что этого достаточно. Это все равно что обчитавшемуся Александреску говорить что boost::lambda корявое убожество.


Если честно, то с тобой вообще разговаривать забавно. Ты как и другие "критики" сами не пробовавшие то о чем рассуждаешь выискиваешь в отдельных языках отдельные фичи которые или не сделаны, или сделаны по другому и на основании этого пыташся найти фатальный недостаток. Вот только проблема в том, что язяки где эти фичи есть обладают куда большим количеством недостатков. Многие из которых действительно фатальны. Вот те же Ди и С++, например в подметки Немерлу не годятся с точки зрения удобства программирвоания. Они вообще только в битовыжимании сильны. Но это же ты в рассчет не берешь?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[65]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:13
Оценка:
Здравствуйте, FR, Вы писали:

FR>Настоящей тотальной ленивости нет, этого как и продолжений макросами не сделать.


Вообще-то можно попытаться.
Вот только зачем нужно делать все на макросах?
И нужно ли вообще делать что-то только на том основании, что кто-то кто слышал о этом "чем-то" приводит это в качеств примера?

Что ты вообще сказать то хочешь этими примерами? Что макросы не всесильны? Ну, это езжу понятно. От этого что-то меняется?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[67]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:13
Оценка:
Здравствуйте, FR, Вы писали:

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


Именно. Вот только у полноценной компилируемой программы таким контекстом является вся память включая стеки потоков. Продолжения в любом языке "неполноценны", так как не делают слепок процесса. Итераторы это частный случай. Конечно он не воспроизводит все паттерны использования континюэшонов, но больую часть их покрывает. Главное, что он позволяет развернуть управление.

Ну, а полные континюэшоны — это файберы (или зеленые потоки как их еще называют). Их можно использовать уже сейчас. Они будут медленее континюэшонов в некторых языках, так как сохраняют больше данных. Но при этом сам язык будет быстрее, так как он компилируемый. В прочем, виртуальная машина позволяет и ограничить контекст. Но это сложна работа. Когда нибудь ее сделают. И работать это решение будет для всех языков дотнета или явя. В Яве подобные работы уже ведутся. Есть котнинюэшон-серверы.

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


Тебе они нужны, ты и делай. Остальным просто не нужны.

FR>Здесь также, порядок тоже можно сделать естественный по мере объвления.


Какого к черту объявления? У тебя сборка может динамически подгрузиться. И в ней может быть расширение мультиметода. В общем, не веди беседы о том, в чем ни в зуб ногой.
Кроме не однозначностей я тебе еще две проблемы раскро:
1. Производительность мультиметодов обратно пропорционально количеству параметров. Хроший универсальный алгоритм тут не существует.
2. Проблемы с днимической загрузкой и безопастностью.

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


FR>Ну бывают и полиморфные варианты и их паттерн матчинг, там точно такие же проблемы.

FR>Кстати немерле подерживает полиморфные варианты? И если нет (или бы не подерживал) то можно их прикрутить макросами?

Все варианты полиморфны априори. Есть понятие GADT. Вот их Немерле не поддерживает по политическим соображениям (это к ошибкам приводит). За то он позволяет наследовать варианты от классов. Вот только боюсь, что для тебя это все птичий язык.

FR>Мне сейчас все хватает, я же Блаб в продолжениях


И не только в них.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[61]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:13
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Да нет, мне это не особо интересно. Просто разговор позабавил


L>- на макросах можно сделать всё

L>- сделай мультиметоды!
L>- мультиметоды — зло

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

И не делать же то что не нужно только ради того, чтобы доказать саму принципиальную возможность этого?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[57]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:13
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Как сделать классы типов на макросах?


Их и без оных не сделать если базова система типов на это не рассчитана.


Вообще, конечно на макросах можно сделать не все. Но и не нужно все делать на макросах. Но то что делается на них, по-моему, не стоит хардкодить в компиляторе.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[53]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:13
Оценка:
Здравствуйте, eao197, Вы писали:

E>Попробуйте довести Nemerle хотя бы до такого состояния.


До какого? Уж судьбу Эфила я бы никому не пожелал.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[55]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:13
Оценка:
Здравствуйте, VoidEx, Вы писали:

EC>>>Вот если бы LINQ приделали на макросах это был бы убийственный аргумент.

WH>>Если бы оно было сильно надо...

VE>Ну уж? Не надо лукавить. Я даже переписку читал, где авторам языка предлагали добавить новый тип макросов специально для того, чтоб можно было реализовать тот же LINQ.

VE>IT не раз говорил, что в таком случае стоит признать, что макросы не могут создавать нормальные DSL, и что все обходные пути реализации LINQ (как то <# select... #> и прочее) — это фигня, а не решение.

VE>А потом решили, что оно не сильно надо. Понятно.


Есть огромная разница между тем можно ли полностью повторить синтаксис другого языка и тем можно ли реализовать фичу на макросах. Вопрос был можно ли реализовать фичу на макросах. Ответ — да. Если вопрос будет можно ли при этом полностью повторить синтаксис Шарпа, то пока ответ будет нет. Но это только пока .

Собственно ЛИНК и будет реализован на макросах. Просто пока до него руки не доходят. То что хочет ИТ есть некоре расширение макросов чтобы они могли полностью брать управление разбором токенов в свои руки и допускать любую модификацию языка. Сейчас же любой макрос обязан удовлетворять некоторым требования Немерле. Среди требований обязательная парность скобок и привязка разделителей к скобкам (например, внутри крулгых скобок разделители должны быть запятыми, а внутри фигурных точками с запятой).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[55]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:13
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Кстати, этот SupportRecolation (если это то, о чём я думаю) — уже обсуждался. Насколько я помню, там показывалось, что на некоторых языках это можно красиво сделать без макросов. И то, что здесь он был сделан на макросах, может говорить о некоторых недостатках (ну или по крайней мере отсутствии некоторых фич) в языке.


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

Так что не надо.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:13
Оценка:
Здравствуйте, Andrei F., Вы писали:

FR>>http://www.digitalmars.com/d/2.0/cpp_interface.html


AF>

Use the limited ability described here to connect directly to C++ functions and classes.

AF>Вот этот пункт — это интересно, не знал что такая возможность есть. Но реально она настолько "limited", судя по описанию, что использовать ее практически нереально.

Реально ее просто нет. Это планы, как я понял. Но если их реализуют, то это уже будет отличным ходом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:13
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>

Я по секрету сознаюсь, что этот компилятор с Модулы уже на пределе допустимой сложности, и я бы чувствовал себя совершенно неспособным создать хороший компилятор для Ады.
Т>Н. Вирт


И ведь не врет ведь! Действительно компилятор для Ады он не сделал!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:13
Оценка:
Здравствуйте, eao197, Вы писали:

E>Собственно, против этого я и не спорил (по крайней мере здесь ). Изначально я хотел узнать, почему это будущее есть только у языков, построенных по принципу Nemerle.


А чего тогда осбуждашь совсем другое?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[56]: C++0x начали урезать
От: VoidEx  
Дата: 07.02.08 18:24
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Есть огромная разница между тем можно ли полностью повторить синтаксис другого языка и тем можно ли реализовать фичу на макросах. Вопрос был можно ли реализовать фичу на макросах. Ответ — да. Если вопрос будет можно ли при этом полностью повторить синтаксис Шарпа, то пока ответ будет нет. Но это только пока .


Конечно, но вся соль синтаксического сахара ( ) как раз в синтаксисе. А LINQ все-таки сахар. Фича — это call/cc, type classes, которые макросам неподвластны. Хотя кто знает.
Re[54]: C++0x начали урезать
От: EvilChild Ниоткуда  
Дата: 07.02.08 18:31
Оценка:
Здравствуйте, WolfHound, Вы писали:

EC>>Я примерно представляю для чего они нужны, но было сказано, что возникла реальная необходимость, и как только захотелось узнать подробности — так сразу НДА и прочие отмазки.

WH>Так эта... см код компилятора там их полно... например SupportRelocation
Ты или коротко поясняй или ссылку давай — я без понятия, что это за штука. Ты ведь не ожидаешь от читателей знания поторохов компилятора?

EC>>Вот если бы LINQ приделали на макросах это был бы убийственный аргумент.

WH>Если бы оно было сильно надо...
Так оно надо хоть зачем-нибудь, за пределами задач решаемых при создании компилятора?
now playing: Autechre — IO
Re[60]: C++0x начали урезать
От: FR  
Дата: 07.02.08 18:35
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Я пока только изучаю продолжения, но кажется файберы тоже только частный случай, они без проблем на call/cc реализуются.

FR>>То есть все что не можем сделать на макросах зло, понятно.


VD>В том то идело, что можно. Только не нужно. О том как реализовать мультиметоды была тема в немерловой конфе. Автор вопроса согласился с камилом, что на макросах все прекрасно реализуюется. Просто учитывая, что есть паттерн-матчинг решающий проблему множественной динамической димпетчиризации, особой необходимости именно в мультиметодах нет. По существу мультиметоды и есть только в КЛОС-е который является макробиблиотекой для ЛИСП-а в котором оных нет. И есть они в КЛОС-е в не малой мере потому, что в ЛИСП-е нет паттерн-матчинга (а потребность в мультидиспатче есть).


Я тоже думаю что можно, их даже на метаклассах питона можно реализовать, но полностью ОО систему из CLOS думаю будет тяжеловато повторить (то что не надо понятно )

FR>>Сравнивай с хаскелем или клейном.


VD>Сравнивл. Разницы не обнаружил. Просто другие умолчания. В нем по умолчанию все лениво, а в Немерле нет. Вот тормозит Хаскель по черному (чтобы его фанаты не говорили) — это да.


Я вижу разницу, в немерле как и в Ocaml (lazy) и в схеме получается слабее.

FR>>>>думаю в этот список можно еще немало вещей добавить и со временем список будет только расти.

WH>>>Попробуй.

FR>>А зачем, ты скажешь или не нужно или приведешь частично коряво сделаную реализацию и скажешь что этого достаточно. Это все равно что обчитавшемуся Александреску говорить что boost::lambda корявое убожество.


VD>Если честно, то с тобой вообще разговаривать забавно. Ты как и другие "критики" сами не пробовавшие то о чем рассуждаешь выискиваешь в отдельных языках отдельные фичи которые или не сделаны, или сделаны по другому и на основании этого пыташся найти фатальный недостаток. Вот только проблема в том, что язяки где эти фичи есть обладают куда большим количеством недостатков. Многие из которых действительно фатальны. Вот те же Ди и С++, например в подметки Немерлу не годятся с точки зрения удобства программирвоания. Они вообще только в битовыжимании сильны. Но это же ты в рассчет не берешь?


Я вообще ничего ни критиковал.
Re[59]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:37
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>И как, позвольте поинтересоваться, amb реализуется на макросах?

VE>А еще хочется узнать, как реализуется на макросах LINQ.

Молча стиснув зубы. Последнее увидите сами. Первое мне без надобности.

ЗЫ

Я правильно понял, что по реализуемости мультиметодов и т.п. вопрос отпал?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:37
Оценка:
Здравствуйте, eao197, Вы писали:

VD>>У D есть автор пашуший на фул-тайм и при этом сделавший язык уступающий Немерлу почти во всем. Кстати, Немерле поддерживает два вида контрактов. Первый как в Ди проверяется в рантайме, а торой как в Sign# по возможности проверяется во время компиляции. Так что и здесь Ди лузер.


E>Смысла этой сентенции не уловил,


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

E>тем более, что для проверки контрактов Spec# использует сторонний инструмент, реализованный другой компанией на Java.


Какая разница, что там используется? Оно есть и работает. И Немерле это дело пддерживает благадоря тем же макросам, а Ди не поддерживает и в билжайшие 5 лет вряд ли будет поддерживать.

К сведению, Москаль перед переходом на работу в МС работал над теорем прувером. И писал он его на Немерле. Почти уверен, что взяли его в МС как раз в связи с этой работой.

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


VD>>А зачем? Такого никто не утверждал.


E>Никто?

E>

E>А настоящее будущее — за Немерле или другими языками, которые будут устроены по тому же принципу.

E>Хотя потом выяснилось, что это было даже не утверждение, а частное мнение.

А где в этих словах "только микроядро и метапрограммирование сейчас являются правильным подходом"?

Зачем вообще подменять обсуждаемую тему?

VD>>Но то что это полезные вещи даже ты наверно не возьмешся опровергать. Не так ли?


E>Когда этими вещами пользуются разработчики компилятора -- мне фиолетово.

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

А как же твои рассказы о конфигах на Руби? Это то самое метапрограммирование и есть. Тебе в руки попался инструмент с гибким синтаксисом и метавозможностями и ты использовал его для того, на что он и рассчитан то не был. Или это ты тоже поставишь под большое сомнение?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:37
Оценка:
Здравствуйте, FR, Вы писали:

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


Это личное мнение, а не обоснование. Мое мнение, что дело в тех кто учит.

VD>>Нет в ФП никаких специальных средств проектирования. ФП это развитие идей структурного программирования. "Сахар", можно сказать (чур меня ).


FR>Gaperton со своей Problem K очень наглядно показал что есть.


Чушь.

FR>Мне кажется ты просто не докурил ФП.


Это твои проблемы, что тебе там кажется.

FR>Я вот тихонько докуриваю но идет туго


Это видно. Надо не курить, а пользоваться. Тогда понимание придет само собой.

- А это курица?
— Не это хавается!



FR>>>Угу только по моему в резулmтате получаются больше "пользователи сахара"


VD>>Если переведешь это предожение на Русский, то можно будет осбудить его.


FR>Очень просто, используются фичи (практически только локальные) из ФП помогающие делать код короче, при этом все, часто даже то, что легко и красиво можно сделать функционально, пишется в смешаном функционально-императивном стиле. Функциональная декомпозиция вообще не применяется. Я не говорю что это одназначно плохо.


Бред, да и только. Тут и обсуждать не чего. Так что ты дава, докуривай. А потом еще раз обсудим.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[61]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:49
Оценка:
Здравствуйте, FR, Вы писали:

FR>Я пока только изучаю продолжения, но кажется файберы тоже только частный случай, они без проблем на call/cc реализуются.


Файберы работают вне языков. Так что это очередная ерунда. Ты можешь написаать call/cc который я смогу использовать из Шарпа? Файберы это те же потоки, только без раздачи квантов времени и с ручным переключением.

FR>Я тоже думаю что можно, их даже на метаклассах питона можно реализовать, но полностью ОО систему из CLOS думаю будет тяжеловато повторить (то что не надо понятно )


Можно и полну. Вот только зачем если в дотете уже готовая есть?

Вообще в Лиспе макросы очень пожожи. Так что противопоставлять их бессмысленно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[57]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.02.08 18:49
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Конечно, но вся соль синтаксического сахара ( ) как раз в синтаксисе. А LINQ все-таки сахар. Фича — это call/cc, type classes, которые макросам неподвластны. Хотя кто знает.


Очередно обсуждение того о чем ничего не понимашь. Мне это надоело. Бредьте в одиночистве. Когда сделаем этот самый ЛИНК не забудьте сказать, что были не правы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[68]: C++0x начали урезать
От: FR  
Дата: 07.02.08 18:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Именно. Вот только у полноценной компилируемой программы таким контекстом является вся память включая стеки потоков. Продолжения в любом языке "неполноценны", так как не делают слепок процесса. Итераторы это частный случай. Конечно он не воспроизводит все паттерны использования континюэшонов, но больую часть их покрывает. Главное, что он позволяет развернуть управление.


Не надо меня за совецкую власть агитировать

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


Файберы тоже частный случай.

FR>>Здесь также, порядок тоже можно сделать естественный по мере объвления.


VD>Какого к черту объявления? У тебя сборка может динамически подгрузиться. И в ней может быть расширение мультиметода. В общем, не веди беседы о том, в чем ни в зуб ногой.

VD>Кроме не однозначностей я тебе еще две проблемы раскро:
VD>1. Производительность мультиметодов обратно пропорционально количеству параметров. Хроший универсальный алгоритм тут не существует.
VD>2. Проблемы с днимической загрузкой и безопастностью.

Ну значит запишем тогда что фиг реализуешь на макросах

FR>>Ну бывают и полиморфные варианты и их паттерн матчинг, там точно такие же проблемы.

FR>>Кстати немерле подерживает полиморфные варианты? И если нет (или бы не подерживал) то можно их прикрутить макросами?

VD>Все варианты полиморфны априори. Есть понятие GADT. Вот их Немерле не поддерживает по политическим соображениям (это к ошибкам приводит). За то он позволяет наследовать варианты от классов. Вот только боюсь, что для тебя это все птичий язык.


Конечно, куда уж мне, у меня от простого call/cc мозги закипают

FR>>Мне сейчас все хватает, я же Блаб в продолжениях


VD>И не только в них.


Ну кто бы говорил
Re[62]: C++0x начали урезать
От: FR  
Дата: 07.02.08 18:59
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Файберы работают вне языков. Так что это очередная ерунда. Ты можешь написаать call/cc который я смогу использовать из Шарпа? Файберы это те же потоки, только без раздачи квантов времени и с ручным переключением.


При чем тут реализация?
Тот же call/cc интересен тем что через него легко реализуются такие вещи которые в языках не подерживающих продолжения можно только хардкорно сделать. Вообще их интересно изучить даже только ради этого. В общем очень мощная штука, хотя склероз подсказывает что в том же Forth есть механизмы (игра со стеком возвратов) почти ему не уступающие.
Re[58]: C++0x начали урезать
От: VoidEx  
Дата: 07.02.08 19:54
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VE>>Конечно, но вся соль синтаксического сахара ( ) как раз в синтаксисе. А LINQ все-таки сахар. Фича — это call/cc, type classes, которые макросам неподвластны. Хотя кто знает.


VD>Очередно обсуждение того о чем ничего не понимашь. Мне это надоело. Бредьте в одиночистве. Когда сделаем этот самый ЛИНК не забудьте сказать, что были не правы.


Так чего ж обсуждаешь?

Не смеши, текущими макросами LINQ не сделаешь, хоть убейся, я в курсе почему. Либо другой синтаксис, либо <# #> (что тоже другой синтаксис) или еще какие костыли. Надо систему макросов менять.
Главное, чтобы ее не приходилось менять на каждый чих
Только, чего ты так бесишься, не пойму, а, ну да... Ты ж сам написал.
Я вообще-то в спор WolfHound и FR встрял, в котором то и дело слышно было, что на макросах можно все, а чего нельзя, то и не нужно. Вот только call/cc как-то не пошел. А тут и выяснилось, что в нем никто ничего не понимает

Ну ладно, раз, как ты сам говоришь, тебе надоели обсуждения, в которых ничего не понимаешь, я сворачиваю дискуссию
Re[42]: C++0x начали урезать
От: FR  
Дата: 07.02.08 20:18
Оценка:
Здравствуйте, VladD2, Вы писали:

FR>>Gaperton со своей Problem K очень наглядно показал что есть.


VD>Чушь.


Видно что ты и курить не пытался

FR>>Я вот тихонько докуриваю но идет туго


VD>Это видно. Надо не курить, а пользоваться. Тогда понимание придет само собой.


Угу надо жевать это же сахар

FR>>Очень просто, используются фичи (практически только локальные) из ФП помогающие делать код короче, при этом все, часто даже то, что легко и красиво можно сделать функционально, пишется в смешаном функционально-императивном стиле. Функциональная декомпозиция вообще не применяется. Я не говорю что это одназначно плохо.


VD>Бред, да и только. Тут и обсуждать не чего. Так что ты дава, докуривай. А потом еще раз обсудим.


Так если я докурю, я же на недокуривших и смотреть не буду, не то что общатся, у злобных функциональщиков так принято
Re[60]: C++0x начали урезать
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 07.02.08 20:24
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>На самом деле тут о чём разговор? О том, что если макросы есть, то всё — можно уже не расширять язык или что?


VD>Нет конечно. Это у FR аргументы кончились вот он и подменил обсуждаемый вопрос. А тема, вообще-то про С++ была. Вот только что-то тут его совсем не обсуждают .


При чём здесь FR? Это я понял со слов WolfHound'а, поэтому переспросил его.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[56]: C++0x начали урезать
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 07.02.08 20:24
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Кстати, этот SupportRecolation (если это то, о чём я думаю) — уже обсуждался. Насколько я помню, там показывалось, что на некоторых языках это можно красиво сделать без макросов. И то, что здесь он был сделан на макросах, может говорить о некоторых недостатках (ну или по крайней мере отсутствии некоторых фич) в языке.


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


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

А так — да, если обязательно нужна кодогенерация (т.е. язык не может предложить лучшее решение), то макросы рулят. С этим никто не спорит.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[58]: C++0x начали урезать
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 07.02.08 21:05
Оценка:
Здравствуйте, VladD2, Вы писали:

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


О! Спор свернул в конструктивное русло

С последней мыслью немного не согласен. Хардкодить в компиляторе, наверное, да, не стоит. На все случаи не напасёшься. Однако, если есть фича, смотрящаяся достаточно стройно в языке, то это лучше, чем макрос в языке, где этой фичи нет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[60]: C++0x начали урезать
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 07.02.08 21:36
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Сравнивл. Разницы не обнаружил. Просто другие умолчания. В нем по умолчанию все лениво, а в Немерле нет. Вот тормозит Хаскель по черному (чтобы его фанаты не говорили) — это да.


Насколько ленивый код в Немерле быстрее, чем аналогичный ленивый код в Хаскель?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[61]: C++0x начали урезать
От: Andrei F.  
Дата: 08.02.08 04:19
Оценка:
Здравствуйте, FR, Вы писали:

FR>В таком случае очень большую часть C++ библиотек будет невозможно использовать.


Библиотеки — это как раз не самое важное. Главная проблема при миграции — это свои собственные проекты, которые обычно нельзя взять и целиком переписать на другом языке. Поэтому нужен интероп. Но ему не обязательно поддерживать абсолютно все возможные случаи, если возникает проблема — код можно упростить.

FR>Более простой и ограниченный интероп уже есть.


Там даже модификаторы соглашения о вызовах не поддерживаются Но вообще, это шаг в правильном направлении.
Re[62]: C++0x начали урезать
От: FR  
Дата: 08.02.08 04:35
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>Библиотеки — это как раз не самое важное. Главная проблема при миграции — это свои собственные проекты, которые обычно нельзя взять и целиком переписать на другом языке. Поэтому нужен интероп. Но ему не обязательно поддерживать абсолютно все возможные случаи, если возникает проблема — код можно упростить.


Пойми реально D сильно отличается от C++. Практически не меньше чем шарп. И продолжить на нем проект не получится.

FR>>Более простой и ограниченный интероп уже есть.


AF>Там даже модификаторы соглашения о вызовах не поддерживаются Но вообще, это шаг в правильном направлении.


Это дело наживное.
Re[64]: C++0x начали урезать
От: FR  
Дата: 08.02.08 05:15
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


На таком уровне с D тоже получится, каких то принципиальных ограничений не видно.
Re[44]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.02.08 06:09
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>У D есть автор пашуший на фул-тайм и при этом сделавший язык уступающий Немерлу почти во всем. Кстати, Немерле поддерживает два вида контрактов. Первый как в Ди проверяется в рантайме, а торой как в Sign# по возможности проверяется во время компиляции. Так что и здесь Ди лузер.


E>>Смысла этой сентенции не уловил,


VD>Объсяняю доходчиво. Автор Ди пока еще слов таких как теорем прувер не знает. Стало быть говорить о поддержке этого в Ди пока бессмысленно.


А никто и не говорил о поддержке в D доказательства корректности контрактов в compile-time.

Для тех, кто в танке, объясняю еще раз: оригинальный Design By Contract, реализованный в Eiffel, содержит специальное ключевое слово old, которое можно использовать только в постусловиях. Оно возвращает значение атрибута/метода, предшествовавшее исполнению тела метода. И именно оно делает возможным проверку в постусловнии корректности работы метода в ряде случаев.

Ни в D, ни в Nice, ни в Nemerle, я не видел возможности использования old в постусловях. Т.е. ни один из этих языков не реализует оригинальной концепции Design By Contract. И компиляторы этих языков созданы на разных принципах. Так какое же преимущество имеет микроядро с макросами Nemerle, если контракты там такие же ущербные, как и в других языках?

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


VD>>>А зачем? Такого никто не утверждал.


E>>Никто?

E>>

E>>А настоящее будущее — за Немерле или другими языками, которые будут устроены по тому же принципу.

E>>Хотя потом выяснилось, что это было даже не утверждение, а частное мнение.

VD>А где в этих словах "только микроядро и метапрограммирование сейчас являются правильным подходом"?


Я полагал, что в словах "которые будут устроены по тому же принципу".
Но если Andrei.F имел в виду что-то другое, пусть уточнит.

VD>>>Но то что это полезные вещи даже ты наверно не возьмешся опровергать. Не так ли?


E>>Когда этими вещами пользуются разработчики компилятора -- мне фиолетово.

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

VD>А как же твои рассказы о конфигах на Руби? Это то самое метапрограммирование и есть. Тебе в руки попался инструмент с гибким синтаксисом и метавозможностями и ты использовал его для того, на что он и рассчитан то не был.


Не понял, что здесь понимается под "гибким синтаксисом". Синтаксис в Ruby менять нельзя. Можно делать только run-time кодогенерацию.

Более того, использование синтаксиса и блоков кода Ruby для декларативных описаний -- это общепринятая практика в Ruby, так что нельзя говорить, что язык на это расчитан не был. И в Ruby вся эта магия делается не макросами, не изменением синтаксиса, а обычными библиотеками.

VD>Или это ты тоже поставишь под большое сомнение?


Вынужден поставить, поскольку видел, во что превращают неокрепшие умы возможности Ruby.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[60]: C++0x начали урезать
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.02.08 08:16
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>На половину. Сам код в компиляторе, но используется макросистема и ее АПИ. В приципе можно было бы и макросом залудить. Тут важна сама возможность анализировать фунцию и генерировать иной ее код. Эта возможность есть. Просто будучи реализованным на макросах синтаксис был бы иной. Например:


А что с функциями, которые вызываются из данной функции. Их нужно переписывать или нет?
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[64]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.02.08 08:44
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


FR>>Пойми реально D сильно отличается от C++. Практически не меньше чем шарп. И продолжить на нем проект не получится.


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


Может тогда расскажите, как решить вышеупомянутую задачку с ACE в .NET?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[66]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.02.08 11:13
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


E>>Может тогда расскажите, как решить вышеупомянутую задачку с ACE в .NET?


AF>Вероятно, придется делать неуправляемый класс-наследник и обертки для управляемых функций.


И после этого вы еще предъявляете какие-то претензии к D?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[45]: C++0x начали урезать
От: WolfHound  
Дата: 08.02.08 11:33
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ни в D, ни в Nice, ни в Nemerle, я не видел возможности использования old в постусловях. Т.е. ни один из этих языков не реализует оригинальной концепции Design By Contract. И компиляторы этих языков созданы на разных принципах. Так какое же преимущество имеет микроядро с макросами Nemerle, если контракты там такие же ущербные, как и в других языках?

Возьми да добавь.
Там все просто.
Вот весь макрос:
  /** Enforces given boolean condition at the end of method invocation.  

      It checks at runtime, that given condition is true at the end
      of each method invocation. The `otherwise' section allows to specify
      what should happen when condition is false (for example throw some
      exception).                                            
  
     Example:  [Ensures (foo () != 4)]
            foo (i : int) : int { ... }
          or
            foo (i : int) : int
             ensures value > 0
            { ... }

          after opening Nemerle.Assertions namespace
   */
  [Nemerle.MacroUsage (Nemerle.MacroPhase.WithTypedMembers,
                       Nemerle.MacroTargets.Method,
                       Inherited = true, AllowMultiple = true)]
  macro Ensures (_ : TypeBuilder, m : MethodBuilder, assertion, other = null)
  syntax ("ensures", assertion, Optional ("otherwise", other))
  {
    def check =
      if (other != null)
        <[ unless ($assertion) $other ]>
      else
        <[ assert ($assertion, "The ``Ensures'' contract of method `" +
                   $(m.Name : string) + "' has been violated.") ]>;
    
    def newBody = Util.locate(m.Body.Location, 
      if (m.ReturnType.Equals (MType.Void ()))
        <[
          $(m.Body);
          $check;
        ]>
      else
        <[
          def $("value" : usesite) = $(m.Body);
          $check;
          $("value" : usesite);
        ]>);
      
      m.Body = newBody;
  }

Все что нужно это запомнить аргументы функции до вызова body и передать их в check.
Думаю с этим даже ты справишься.

E>Более того, использование синтаксиса и блоков кода Ruby для декларативных описаний -- это общепринятая практика в Ruby, так что нельзя говорить, что язык на это расчитан не был. И в Ruby вся эта магия делается не макросами, не изменением синтаксиса, а обычными библиотеками.

А макросы чем тебе не библиотеки?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[48]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.02.08 12:53
Оценка:
Здравствуйте, WolfHound, Вы писали:

E>>Я уже пытался объяснять про проблемы совместного использования нескольких разных синтаксических макросов с одинаковыми ключевыми словами. Но вам выгоднее не обращать на них внимания. Хотя как раз в этом отличие между макросами и библиотеками и состоит -- в отсутствии конфликтов.

WH>Не делай using и используй макрос как вызов функции. Делов то.

Может покажешь, как макросы require и ensure использовать как вызов функции?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[46]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.02.08 13:16
Оценка:
Здравствуйте, WolfHound, Вы писали:

E>>Ни в D, ни в Nice, ни в Nemerle, я не видел возможности использования old в постусловях. Т.е. ни один из этих языков не реализует оригинальной концепции Design By Contract. И компиляторы этих языков созданы на разных принципах. Так какое же преимущество имеет микроядро с макросами Nemerle, если контракты там такие же ущербные, как и в других языках?

WH>Возьми да добавь.
WH>Там все просто.
WH>Вот весь макрос:

Собственно, вот как реализуются контракты в Nice:
Граматика:
Contract contract() :
{
  Contract res = bossa.syntax.fun.noContract;
  Expression condition, name;
}
{
  [ "requires" { res = new Contract(); }
    contractElements(res, true)
  ]
  [ "ensures" { if (res == bossa.syntax.fun.noContract) res = new Contract(); }
    contractElements(res, false)
  ]
  { return res; }
}

void contractElements(Contract contract, boolean precond) :
{}
{
  contractElement(contract, precond)
  ( "," [ // Trailing "," allowed for easy reordering, removal of last line..
    contractElement(contract, precond)
  ] )*
}

void contractElement(Contract contract, boolean precond) :
{ Expression condition, name=null; }
{
  condition = SideEffectFreeExpression()
  [ ":" name = SideEffectFreeExpression() ]
  { contract.addElement(condition, name, precond); }
}

и еще чуть-чуть в AST компилятора:
/**
   The contract of a method.

 */
public class Contract
{
  private List<Expression> pre  = new LinkedList();
  private List<Expression> post = new LinkedList();

  private StringBuffer requireRepr = new StringBuffer("requires ");
  private StringBuffer ensureRepr = new StringBuffer("ensures ");

  public void addElement(Expression condition, ?Expression name, boolean precond)
  {
    let sym = createIdentExp(new LocatedString("!assert", condition.location()));

    Expression call;
    String repr;
    if (name == null)
      {
        call = createCallExp(sym, condition);
        repr = condition.toString() + ",";
      }
    else
      {
        call = createCallExp(sym, condition, name);
        repr = condition.toString() + ":" + name.toString() + ",";
      }

    if (precond)
      {
        pre.add(call);
        requireRepr.append(repr);
      }
    else
      {
        post.add(call);
        ensureRepr.append(repr);
      }
  }

  void resolve(VarScope scope, TypeScope typeScope,
           mlsub.typing.Monotype resultType,
               Location location)
  {
    pre = pre.map(Expression e => analyse(e, scope, typeScope));

    if (post.isEmpty())
      return;

    SymbolTable<VarSymbol> vars = new SymbolTable();

    // Make 'result' a variable in the scope of the post-conditions
    if (! nice.tools.typing.Types.isVoid(resultType))
      vars["result"] = new ResultMonoSymbol
        (new LocatedString("result", location), type: resultType);

    post = post.map(Expression e => analyse(e, scope, typeScope, vars));
  }

  void typecheck()
  {
    for (pe : pre)
      typecheck(pe);

    for (pe : post)
      typecheck(pe);
  }

  public gnu.expr.Expression compile(gnu.expr.Expression body)
  {
    return new gnu.expr.CheckContract(Expression_compile(pre), 
                      Expression_compile(post), 
                      body);
  }

  toString()
  {
    StringBuffer res = new StringBuffer();
    if (! pre.isEmpty())
      res.append(requireRepr.toString());
    if (! post.isEmpty())
      res.append(ensureRepr.toString());
    return res.toString();
  }

}

let Contract noContract = new NoContract();

class NoContract extends Contract
{
  resolve(scope, typeScope, resultType, location) {}
  typecheck() {}
  compile(body) = body;
  toString() = "";
}

class ResultMonoSymbol extends MonoSymbol
{
  isAssignable() = false;
  compile() = gnu.expr.CheckContract.result;
}


Ты серьезно думаешь, что реализация на Nice на порядки сложнее таковой в Nemerle?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[49]: C++0x начали урезать
От: WolfHound  
Дата: 08.02.08 13:43
Оценка:
Здравствуйте, eao197, Вы писали:

E>Может покажешь, как макросы require и ensure использовать как вызов функции?

Их можно использовать с синтаксисом атрибутов.
Ты бы хоть камент к Ensures посмотрел.
     Example:  [Ensures (foo () != 4)]
            foo (i : int) : int { ... }
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[47]: C++0x начали урезать
От: WolfHound  
Дата: 08.02.08 13:43
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ты серьезно думаешь, что реализация на Nice на порядки сложнее таковой в Nemerle?

Да.
То что я привел полный код макроса ensures.
Если бы не уродская система типов .NET'а (в данном случае пакостит тип void) то макрос был бы еще короче.
Добавление old туда добавит еще строк 5-10.
И это при том что этот макрос опциональный и его добавление/удаление не влияет на ядро компилятора вобще. Те совсем никак.
Болие того этот макрос вполне могли написать посторонние люди, а авторы компилятора просто заапрувить.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[55]: C++0x начали урезать
От: WolfHound  
Дата: 08.02.08 13:49
Оценка:
Здравствуйте, eao197, Вы писали:

E>А теперь вопрос: ты не пожелаешь Nemerle иметь проекты такого масштаба, объемы продаж которых будут исчисляться десятками тысяч копий?

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

Так что мое мнение: Eiffel провальный проект.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[56]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.02.08 13:54
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


E>>А теперь вопрос: ты не пожелаешь Nemerle иметь проекты такого масштаба, объемы продаж которых будут исчисляться десятками тысяч копий?

WH>Десятки тысяч это просто ничто.

Продукты на Nemerle уже достигли такого уровня продаж?

WH>Так что мое мнение: Eiffel провальный проект.


Eiffel, по крайней мере, 20 лет кормил своего создателя и еще команду разработчиков EiffelStudio.

Способен ли на это Nemerle?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[49]: C++0x начали урезать
От: WolfHound  
Дата: 08.02.08 14:29
Оценка:
Здравствуйте, eao197, Вы писали:

E>То, что я привел, содержит не только код макроса ensures, но и макроса requires,

Угу... смешать все в кучу... прелесно.
Кстати как там у Nice с сообщениями о ошибках
Автор: Klapaucius
Дата: 01.02.08
?

E>а так же код, отвечающий за pretty-print этих вещей.

Это ваще шедевр. За такой код в приличном обществе руки отрывают.

E>Есть у меня подозрения, что это будет не совсем так.

Проверь.
Мне данные конкретные макры (и темболие old в них) не нужны.

E>А вот пользователям языка это побарабану. Об этом уже много раз говорили.

Пользователи бывают разные.
E>Язык должен предоставлять базовый набор средств пользователям.
А что немерле не предоставляет
E>И без разницы, как этот базовый набор реализуется -- макросами или изменением грамматики.
Нет не безразници.
Если нужно менять граматику то это затронет всех, а не тех кому эти макры нужны.
Если нужно менять граматику то я не смогу добавить макру которая нужна только мне.
Если нужно менять граматику то это значительно усложняет разработку и как следствие колличество и качество фич оставляет жилать лучшего.
Как там с сообщениями об ошибках у Nice? А где я могу посмотреть на аналоги Memoize и Late для D?
...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[50]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.02.08 14:40
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


E>>То, что я привел, содержит не только код макроса ensures, но и макроса requires,

WH>Угу... смешать все в кучу... прелесно.

Если ты не заметил, то там класс-наследник Expression и он реализует его методы. В каждом методе свой набор действий, которые не смешиваются.

WH>Кстати как там у Nice с сообщениями о ошибках
Автор: Klapaucius
Дата: 01.02.08
?


Жить можно. Klapaucius для красного словца убрал строку, в которой печатается имя файла, номер строки и столбца в строке. Так что диагностирует место возникновение ошибки nicec точно. А что вывод такой -- так лучше пусть такой, чем то, что позволяет себе MS VC++ 2003. Тот вообще, на ошибку в имени типа параметра в конструкторе выдает сообщение о синтаксической ошибке в совсем другой строке.

E>>а так же код, отвечающий за pretty-print этих вещей.

WH>Это ваще шедевр. За такой код в приличном обществе руки отрывают.

Странно, что после вот этого кода
Автор: WolfHound
Дата: 04.02.08
(там где через ssh сервер пингуется) ты еще с руками ходишь.

E>>Есть у меня подозрения, что это будет не совсем так.

WH>Проверь.
WH>Мне данные конкретные макры (и темболие old в них) не нужны.

Неумение пользоваться чем-то еще не означает его ненужности.

E>>А вот пользователям языка это побарабану. Об этом уже много раз говорили.

WH>Пользователи бывают разные.
E>>Язык должен предоставлять базовый набор средств пользователям.
WH>А что немерле не предоставляет
E>>И без разницы, как этот базовый набор реализуется -- макросами или изменением грамматики.
WH>Нет не безразници.
WH>Если нужно менять граматику то это затронет всех, а не тех кому эти макры нужны.

Если эта функциональность входит в ядро языка, то она и должна затрагивать всех.

WH>Если нужно менять граматику то я не смогу добавить макру которая нужна только мне.


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

WH>А где я могу посмотреть на аналоги Memoize и Late для D?


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[51]: C++0x начали урезать
От: WolfHound  
Дата: 08.02.08 15:03
Оценка:
Здравствуйте, eao197, Вы писали:

E>Странно, что после вот этого кода
Автор: WolfHound
Дата: 04.02.08
(там где через ssh сервер пингуется) ты еще с руками ходишь.

И что тебе там не нравится?

E>Если эта функциональность входит в ядро языка, то она и должна затрагивать всех.

А ты уверен что аналог макроса Late должен входить в ядро?
Я нет.

E>По мне, так это только плюс для универсального языка.

Неумение пользоваться чем-то еще не означает его ненужности.
(С) Сам знаешь кто.

E>А какие гарантии предоставляет Memoize в многопоточной программе?

[Memoize(Synchronized = true)]
E>А по исключениям? А если мне нужны другие гарантии?
А тебе не нужна безопасность по отношения к исключениям? Интересное жилание.
E>Собственный макрос делать? Тогда зачем Memoize в стандартной поставке языка?
Притензия из серии: Мне не нравится std::map! Зачем ее засунули в stl?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[52]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.02.08 15:17
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


E>>Странно, что после вот этого кода
Автор: WolfHound
Дата: 04.02.08
(там где через ssh сервер пингуется) ты еще с руками ходишь.

WH>И что тебе там не нравится?

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

E>>Если эта функциональность входит в ядро языка, то она и должна затрагивать всех.

WH>А ты уверен что аналог макроса Late должен входить в ядро?
WH>Я нет.

На счет макроса Late не могу сказать, т.к. не знаю, что это такое. А вот Memoize, в отличии от Design By Contract в ядре точно не место. Разве что в стандартной библиотеке.

E>>По мне, так это только плюс для универсального языка.

WH>Неумение пользоваться чем-то еще не означает его ненужности.
WH>(С) Сам знаешь кто.

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

E>>А какие гарантии предоставляет Memoize в многопоточной программе?

WH>[Memoize(Synchronized = true)]
E>>А по исключениям? А если мне нужны другие гарантии?
WH>А тебе не нужна безопасность по отношения к исключениям? Интересное жилание.
E>>Собственный макрос делать? Тогда зачем Memoize в стандартной поставке языка?
WH>Притензия из серии: Мне не нравится std::map! Зачем ее засунули в stl?

Согласен, здесь я привел неудачный пример.
В D, думаю, аналог Memoize, можно сделать как шаблонную обертку над методом. И вызвать потом не сам метод, а его обертку. Так же можно поступать и в Nice, хотя здесь могут быть сложности с переменным числом аргументов.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[55]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 15:39
Оценка:
Здравствуйте, eao197, Вы писали:

E>Всего EiffelStudio (опять же по словам Мейера) была продана в количестве десятков тысяч копий (причем каждая копия стоит значительно дороже $1000).


Анекдот в тему.

............
— Доктор! У меня проблемы с женщинами в постели.
— Так что же вы хотите, голубчик, в ваши то 78 лет?
— Так у меня соседу вообще 80, а он говорит, что еще ОГО-ГО!
— Ну, так и Вы говорите...


Думаю, в современных условиях он вообще мало что смог бы продать. А $10 за десятки лет — это не доход. Он ведь не все в корман кладет? Ему же надо с работниками делиться и т.п.

Я сужу о распространенности продукта по спросу на него. Покажи мне хотя бы один вопрос по этому замечательному языку у нас на форуме. Нет? А на другом не принадлежащем ему?
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[69]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 15:39
Оценка:
Здравствуйте, FR, Вы писали:

FR>Файберы тоже частный случай.


В чем их частность?

VD>>Какого к черту объявления? У тебя сборка может динамически подгрузиться. И в ней может быть расширение мультиметода. В общем, не веди беседы о том, в чем ни в зуб ногой.

VD>>Кроме не однозначностей я тебе еще две проблемы раскро:
VD>>1. Производительность мультиметодов обратно пропорционально количеству параметров. Хроший универсальный алгоритм тут не существует.
VD>>2. Проблемы с днимической загрузкой и безопастностью.

FR>Ну значит запишем тогда что фиг реализуешь на макросах


Пиши что хочешь. Тебе ведь вообще пофигу что и где писать. Адью.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[63]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 15:39
Оценка:
Здравствуйте, FR, Вы писали:

FR>При чем тут реализация?


Притом, что если плевать на все (в том числе на производительность), то реализовать можно почти все.

FR>Тот же call/cc интересен тем что через него легко реализуются такие вещи которые в языках не подерживающих продолжения можно только хардкорно сделать.


Ну, хотя бы один пример можно привести чтобы он на файберах при этом не воспроизводился и за одно нес хотя бы что-то полезное, а не был бы самоцелью?
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[53]: C++0x начали урезать
От: WolfHound  
Дата: 08.02.08 15:42
Оценка:
Здравствуйте, eao197, Вы писали:

E>По мне, так там сильно много разнообразных действий в одном месте намешано

А что там намешано?
Там по уже распарсеному конфигу строятся необходимые структуры данных и запускаются необходимые для работы демоны.

E>, злоупотребление локальными функциями.

И что бы по твоему изменилось если бы я их не использовал?
А я тебе скажу: Пришлось бы завести еще пару классов. И раздуть код раза в 2. Минимум.

E>На счет макроса Late не могу сказать, т.к. не знаю, что это такое. А вот Memoize, в отличии от Design By Contract в ядре точно не место. Разве что в стандартной библиотеке.

Так они там и находится.

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

А в чем проблема?
Ибо библиотеками особенно под С/С++ дров можно наломать как минимум не меньше.

E>Согласен, здесь я привел неудачный пример.

E>В D, думаю, аналог Memoize, можно сделать как шаблонную обертку над методом. И вызвать потом не сам метод, а его обертку. Так же можно поступать и в Nice, хотя здесь могут быть сложности с переменным числом аргументов.
В том то и прелесть макросов что я написал и отладил этот код (Problem178)
Автор: WolfHound
Дата: 04.02.08
для маленьких значений, а потом просто дописал Memoize и получил дикое ускорение.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[56]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.02.08 15:59
Оценка:
Здравствуйте, VladD2, Вы писали:

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


E>>Всего EiffelStudio (опять же по словам Мейера) была продана в количестве десятков тысяч копий (причем каждая копия стоит значительно дороже $1000).


VD>Думаю, в современных условиях он вообще мало что смог бы продать. А $10 за десятки лет — это не доход. Он ведь не все в корман кладет? Ему же надо с работниками делиться и т.п.


Какие $10? Ты бредишь? На цены посмотри

VD>Я сужу о распространенности продукта по спросу на него. Покажи мне хотя бы один вопрос по этому замечательному языку у нас на форуме. Нет? А на другом не принадлежащем ему?


Блин, Влад, раскрой глаза! Ты серьезно думаешь, что RSDN является объективным отражением того, что творится в мире? Актись. Я прекрасно помню, как два года назад ты спрашивал "Какой-такой Ruby?" А сейчас вы статьи о нем публикуете.
Eiffel же стоит столько, что в бывшем Союзе мало кто может себе его позволить использовать в разработках. Так что же ты хотел на русскоязычном форуме?

Я задавал вопросы по Eiffel здесь: eiffel_software -- отвечали достаточно грамотно и оперативно. Хотя и фанатики типа тебя, там так же встречались.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[55]: C++0x начали урезать
От: WolfHound  
Дата: 08.02.08 16:51
Оценка:
Здравствуйте, eao197, Вы писали:

E>У меня, наверное, воспитание другое. Но по мне, более объемый но простой код гораздо лучше компактного, но более сложного.

Куда уж проще?
Код прост как пробка.

E>Речь о другом -- по-моему, сопровождать и развивать библиотеку проще, чем язык (пусть даже и DSL). И если язык не предоставляет своим пользователям возможности для своего расширения (а только за счет библиотек функций и классов), то в долгосрочной перспективе это окупается простотой сопровождения, переработки и перехода на другие библиотеки.


Я плакал.
Ибо если у нас в 10 раз больше кода то у нас минимум в 10 раз больше гемороя при поддержке.
А правильный макрос в правильном месте может дать и больше.
Конечно не на всех задачах но иногда такие встречаются.

E>Думаю, что если бы Memoize был реализован на D-шных шаблонах, эффект получился практически таким же. Было бы что-то вроде:

1)Это называется через зад автогеном.
2)Эта штука будет различать static и instance методы?
3)А можно таки посмотреть на этот самый шаблон memoize?

E>Кстати, по ходу вопрос -- Memoize на локальные функции распространяется?

В текущей реализации нет.
Нужно просто определиться как он будет вести себя для локльных функций.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[64]: C++0x начали урезать
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.02.08 16:53
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну, хотя бы один пример можно привести чтобы он на файберах при этом не воспроизводился и за одно нес хотя бы что-то полезное, а не был бы самоцелью?


Тебе кучу раз приводили continuation-сервера. Ну, не делается оно полноценно на фиберах.
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[69]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 17:11
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Полиморфные варианты — это не АТД


С чего бы это?

L>Это такие конструкторы, отвязанные от типа. Они есть, например, в OCaml.


Тогда давай свое определение. А то похоже спор снова о терминх.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[61]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 17:11
Оценка:
Здравствуйте, lomeo, Вы писали:

VD>>Сравнивл. Разницы не обнаружил. Просто другие умолчания. В нем по умолчанию все лениво, а в Немерле нет. Вот тормозит Хаскель по черному (чтобы его фанаты не говорили) — это да.


L>Насколько ленивый код в Немерле быстрее, чем аналогичный ленивый код в Хаскель?


Думаю, что завист от ситуации. Может и не на сколько. Вот то что сам Хаскель порой в 10, 100, а то и в 1000 раз медленнее это факт. А пользователя его не трогает мегакрутость ззыка. Ему ехать надо.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[61]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 17:11
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>А что с функциями, которые вызываются из данной функции. Их нужно переписывать или нет?


Как резонно заметили некоторые товарищи Итераторы не полноценные континюэшоны. Это скажем так их сабсэт. Итераторы "замыкают" только локальные переменный метода. Так что переписывать вызваемые методы нет смысла.

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

Я уже много раз говорил, что в компилируемомо статически типизированном языке смысла делать полноценные континюэшоны не много. Они не будут быстрее тех же файберов. Но вот сделать нечто большее чем Итераторы было бы не плохо. Как минимум разные воркылоу-задачи решать было бы удобнее.

Вот это сделать на макросах можно. В прочем можно, наверно и полные континюэшоны залудить. Вот только почти уверен, что объем сохраняемой информции будет велик и стало быть выхлоп будет холостым.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[57]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 17:11
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Если говорить откровенно, то я этого момента не помню. Напомни, плз, что за конкретные места и что за анализ, для которых нужна генерация кода? Или ссылку дай на сообщение.


Код доступен http://nemerle.org/svn/nemerle/trunk/macros/compiler.n изучай.

L>А так — да, если обязательно нужна кодогенерация (т.е. язык не может предложить лучшее решение), то макросы рулят. С этим никто не спорит.


Ну, может в некотором проценте случае тот или иной язык предложить не то что бы лучшее, но хоть какое-то решение. И что это основание пользователям других языков говорить о ненужности макросов? Есть хоть один язык который идеально решает все встающие перед программистом задачи? Ну, тогда о чем речь? Ну, есть в Хаскеле 5-10 классных фич и решений? Но мн с того не жарко не холодно. Писать на нем сожно. Код получается, зачастую, неприемлемо медленным. Кривая изучения языка выше Монблана.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 17:11
Оценка:
Здравствуйте, eao197, Вы писали:

E>Может покажешь, как макросы require и ensure использовать как вызов функции?

Nemerle.Assertions.Requires(...)
SomeMethod(...)
{
  ...
}


Еще впоросы? Предвосхищаю... Макрос requires — это синтаксис к метаатрибуту Nemerle.Assertions.Requires. Реализацию можно поглядеть здесь:
http://nemerle.org/svn/nemerle/trunk/macros/assertions.n

ЗЫ

Что-то мне подсказывет, что сейчас будут искаться еще какие-то бредовые отговорки, но признания твоего заблуждения в данном вопросе мы так и не услышим. Хотя оно столь очевидно.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[51]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 17:11
Оценка:
Здравствуйте, eao197, Вы писали:

E>Тогда два вопроса:


E>* если все это можно сделать без макросов, на анотациях, то зачем макросы?


Да, и я понимаю Колхоза. Это же уже все пределы переходит!

Запомни раз и на всегда. Макросы могут иметь форму пользовательских атрибутов. А лучше, просто прочти цикал статей о макросах:
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[57]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 17:28
Оценка:
Здравствуйте, eao197, Вы писали:

E>Какие $10? Ты бредишь? На цены посмотри


$10 M, естественно, т.е. 10 000 000. Это отнюдь не много для 20 лет. Это просто мизер.

VD>>Я сужу о распространенности продукта по спросу на него. Покажи мне хотя бы один вопрос по этому замечательному языку у нас на форуме. Нет? А на другом не принадлежащем ему?


E>Блин, Влад, раскрой глаза! Ты серьезно думаешь, что RSDN является объективным отражением того, что творится в мире?


Я серьезно считаю, что если бы язык был реально популярен, то из 100 000 посетителей этого сайта хотя бы один его использовал бы.

E> Актись. Я прекрасно помню, как два года назад ты спрашивал "Какой-такой Ruby?" А сейчас вы статьи о нем публикуете.


Пользователей руби я знаю. Вот ты, например. Их не много, но они есть. А вот Эфиля. Ну, не видел ни одного. Ни в жувую, ни на сайтах. Точнее одно видел в живую. Автра.

E>Eiffel же стоит столько, что в бывшем Союзе мало кто может себе его позволить использовать в разработках. Так что же ты хотел на русскоязычном форуме?


Ага. За Студию по $10 000 на одно раб.место платят, а Эйфиль позволить не моут. Слишком крут видмо он.

E>Я задавал вопросы по Eiffel здесь: eiffel_software -- отвечали достаточно грамотно и оперативно. Хотя и фанатики типа тебя, там так же встречались.


Ты меня путашь с кем-то. Я реалист. А вот ты сказочник. Даже не сказочник, а сказочный герой. Придумал себе мир и недоволен, что другие в него не верят.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.08 17:48
Оценка:
Здравствуйте, eao197, Вы писали:

E>А вот пользователям языка это побарабану. Об этом уже много раз говорили. Язык должен предоставлять базовый набор средств пользователям. И без разницы, как этот базовый набор реализуется -- макросами или изменением грамматики.


Ну, вот именно по этому пользователи Ди боятся на нем что-то писать, так как даже сам автор не может обеспечить обратной совместимости. А у того же Немерла работают исходники двух-летней давности. Все потому, что одни меняет синтаксис и семантику, а другие пользуются продуманным средством расширения. Полный аналог этого если бы в языке нельзя было использовать библиотек, а приходилось все в язык хардкодить.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[70]: C++0x начали урезать
От: FR  
Дата: 08.02.08 19:19
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Это такие конструкторы, отвязанные от типа. Они есть, например, в OCaml.


VD>Тогда давай свое определение. А то похоже спор снова о терминх.


http://caml.inria.fr/pub/docs/manual-ocaml/manual006.html#htoc41
Re[70]: C++0x начали урезать
От: FR  
Дата: 08.02.08 19:20
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>Файберы тоже частный случай.


VD>В чем их частность?


В том что щни легко реализуются через продолжения, обратное неверно.
Re[64]: C++0x начали урезать
От: FR  
Дата: 08.02.08 19:21
Оценка:
Здравствуйте, VladD2, Вы писали:

FR>>Тот же call/cc интересен тем что через него легко реализуются такие вещи которые в языках не подерживающих продолжения можно только хардкорно сделать.


VD>Ну, хотя бы один пример можно привести чтобы он на файберах при этом не воспроизводился и за одно нес хотя бы что-то полезное, а не был бы самоцелью?


Так тебе уже привели, но ты токуешь
Re[62]: C++0x начали урезать
От: FR  
Дата: 08.02.08 19:28
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну, начнем с того, в общем-то можно. Смысл нет, но можно. А зкончим тем, что если что-то нельзя, то это что-то просто должно отнаситься к тому самому микроядру. Ну, вот нельзя в микроядерной ОС организовать передачу информации в обход микроядра, ну, так это зе не значит, что сам подход не приемлем. Правда?


В общем-то да можно, пока реально не начнешь делать.

VD>Наши заслуженные демогоги FR & eao197 в очередной раз сделали логический подлог, а вы поддержали их почин.


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

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


Мое болото тут совсем не упоминалось, рассматривали только ваше.
Re[57]: C++0x начали урезать
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.02.08 21:21
Оценка:
Здравствуйте, eao197, Вы писали:

E>Eiffel же стоит столько, что в бывшем Союзе мало кто может себе его позволить использовать в разработках.


Ты очень плохо себе представляешь, кто и что может позволить себе в разработках.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[61]: C++0x начали урезать
От: VoidEx  
Дата: 09.02.08 04:45
Оценка:
Ну все, интернет-общение дает знать о себе...
"Бескультурья", конечно. Стыдно в без- и бес- ошибаться.
Re[56]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.02.08 07:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

E>>Речь о другом -- по-моему, сопровождать и развивать библиотеку проще, чем язык (пусть даже и DSL). И если язык не предоставляет своим пользователям возможности для своего расширения (а только за счет библиотек функций и классов), то в долгосрочной перспективе это окупается простотой сопровождения, переработки и перехода на другие библиотеки.

WH>
WH>Я плакал.

Я работаю на проектах, которые были запущены в эксплуатацию раньше, чем появился Nemerle.
Когда кто-то из вас пройдет такой же путь в реальном проекте на Nemerle, тогда и наступит время плакать или смеятся.

WH>3)А можно таки посмотреть на этот самый шаблон memoize?


Я уже давно не программировал на D. Так что не могу удовлетворить твоего любопытства.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[48]: C++0x начали урезать
От: FR  
Дата: 09.02.08 07:28
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Слушай. Ты форумом ошибся. Тут не демогогический клуб, а технический. Кончай упражняться.


Похоже все-таки религиозный.
Я сюда тоже редко заглядывал думал уже фанатизм поутих, но похоже это неизлечимо
Re[56]: C++0x начали урезать
От: FR  
Дата: 09.02.08 08:34
Оценка:
Здравствуйте, WolfHound, Вы писали:


WH>3)А можно таки посмотреть на этот самый шаблон memoize?


Насчет Memoize, его можно сделать вручную и не переписывая исходной функции и на D и на C++ и на шарпе, просто на виртуальных функциях, вот набросок на D:

import std.stdio;

class M0
{
    public long fib(long n)
    {
        if(n < 2) return 1;
        return fib(n -1) + fib(n - 2);
    }
}

class M1 : M0
{
    long m[long];
    
    public long fib(long n)
    {
    if(n in m)  return m[n];
    //writefln(n);    
    long r = super.fib(n); 
    m[n] = r;
    return  r;
    }
}


void main()
{
    auto m = new M1;
    writefln(m.fib(50));
}


Завернуть это в шаблон или текстовый миксин не сложно.
Re[62]: C++0x начали урезать
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.02.08 11:24
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Насколько ленивый код в Немерле быстрее, чем аналогичный ленивый код в Хаскель?


VD>Думаю, что завист от ситуации. Может и не на сколько. Вот то что сам Хаскель порой в 10, 100, а то и в 1000 раз медленнее это факт. А пользователя его не трогает мегакрутость ззыка. Ему ехать надо.


Ну, ты говорил, что сравнивал. Теперь вот даже конкретные цифры привёл.

Вопросы

1. Для каких задач (если можно исходники) Хаскель медленнее в 10, 100 и в 1000 раз? Я так понимаю, что медленнее, чем Немерле, да?

2. Хотелось бы всё таки до конца разобраться с ленивостью в Немерле. Есть ли там strictness analysis наример?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[62]: C++0x начали урезать
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.02.08 12:25
Оценка:
Здравствуйте, VladD2, Вы писали:

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

P.S. Спорить о споре, честно говоря, не очень хочется
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[69]: C++0x начали урезать
От: Andrei F.  
Дата: 11.02.08 06:37
Оценка:
Здравствуйте, eao197, Вы писали:

E>Одна из самых сложных вещей в программировании -- делать именно то, что нужно заказчику. А логика в этом деле далеко не помошник.


Логика — отличный помощник, чтобы подумать и за себя, и за тупого заказчика. Главное, не забыть взять за это деньги.
Re[70]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.08 07:17
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


E>>Одна из самых сложных вещей в программировании -- делать именно то, что нужно заказчику. А логика в этом деле далеко не помошник.


AF>Логика — отличный помощник, чтобы подумать и за себя, и за тупого заказчика. Главное, не забыть взять за это деньги.


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

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[71]: C++0x начали урезать
От: Andrei F.  
Дата: 11.02.08 07:59
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ладно бы вы меня тупым считали, я уже привык, это даже выгодно.


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

E>Но если вы и своих заказчиков тупыми считаете... А ведь это люди, которые смогли своим умом заработать деньги на многое, в том числе, чтобы и заказать у вас ПО.


Далеко не все заказчики тупые. Но те, которые не могут внятно объяснить, чего они хотят — точно тупые.
И кто сказал, что они заработали деньги "своим умом"? Кто-то родился у богатых родителей, кто-то в богатой стране, кто-то просто хорошо умеет задницы лизать... э, пардон, имеет большие навыки в области дипломатии.
Те, кто добились всего своим умом — они как раз четко знают, чего хотят и в каком порядке.
Re[69]: C++0x начали урезать
От: Andrei F.  
Дата: 11.02.08 08:08
Оценка:
Здравствуйте, eao197, Вы писали:

E>С удовольствием посмотрел бы на ваш вариант этого списка.


Для меня основная задача интеропа — возможность вызывать legacy-код из моего кода. В C++/CLI эта задача решена хорошо. Таким образом, по этому пункту — серьезное преимущество у C++/CLI, а по обратной задаче (вызов нового кода из legacy-кода) мы имеем паритет.
Re[66]: C++0x начали урезать
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.02.08 09:42
Оценка:
Здравствуйте, VladD2, Вы писали:

ANS>>Тебе кучу раз приводили continuation-сервера. Ну, не делается оно полноценно на фиберах.


VD>Что не делается? Только без мозго...ства. Кокретный простой пример... и плиз чтобы он не был ради себя самого.


Судя по смайлику, пример не последует. Так и запишем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[67]: C++0x начали урезать
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 11.02.08 10:23
Оценка:
Здравствуйте, VladD2, Вы писали:

ANS>>>Тебе кучу раз приводили continuation-сервера. Ну, не делается оно полноценно на фиберах.


VD>>Что не делается? Только без мозго...ства. Кокретный простой пример... и плиз чтобы он не был ради себя самого.


VD>Судя по смайлику, пример не последует. Так и запишем.


Влад, я не знаю как еще написать фразу "continuation-сервера". Пример конкретный и практичный. Что интересно его мы уже разбирали
Автор: Andrei N.Sobchuck
Дата: 07.04.05
.
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[71]: C++0x начали урезать
От: Andrei F.  
Дата: 11.02.08 11:33
Оценка:
Здравствуйте, eao197, Вы писали:

E>Выделенное является слишком расплывчатой формулировкой.


Если тебе не нравится моя формулировка — предлагай свою.
Re[57]: C++0x начали урезать
От: WolfHound  
Дата: 11.02.08 17:04
Оценка:
Здравствуйте, eao197, Вы писали:

E>Вот, надоело сегодня целый день документацию писать, решил душу отвести. В самом примитивном виде memoize на D2.0 выглядит так (наверное, что-то похожее можно и на D1.0 сделать):

Надеюсь ты сам понимаешь насколько это решение ущербно по сравнению с оригинальным макросом.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[58]: C++0x начали урезать
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.02.08 19:00
Оценка:
Здравствуйте, FR, Вы писали:

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



E>>- static memory объявлено только для простоты. По хорошему надо бы иметь асоциативный вектор созданных делегатов, в котором ключем будет аргумент dg. Ну и защитить его семафором для поддержки многопоточности;


FR>Так убери статик, замыкания же теперь нормально подерживаются


А ведь точно! Спасибо,

E>>- корявый код с использованием структуры Key и foreach-а для заполнения объекта k нужен из-за особенностей реализации D-шных туплов. Объявить тупл в качестве типа ключа в ассоциативном массиве в D можно, а вот задействовать реально его в качестве ключа у меня не получилось. Тут либо я идиот, либо действительно лыжи не едут;


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


Так легкое получение аргументо в виде тупла и сейчас есть в шаблонах. Или ты о другом?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[59]: C++0x начали урезать
От: FR  
Дата: 11.02.08 20:03
Оценка:
Здравствуйте, eao197, Вы писали:

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


E>Так легкое получение аргументо в виде тупла и сейчас есть в шаблонах. Или ты о другом?


Было бы удобно если бы каждая функция имела неявную переменную arguments в виде тупла (примерно как в функциях с переменным числом аргументов).
Re[57]: C++0x начали урезать
От: FR  
Дата: 12.02.08 05:47
Оценка:
Здравствуйте, eao197, Вы писали:

E>Вот, надоело сегодня целый день документацию писать, решил душу отвести. В самом примитивном виде memoize на D2.0 выглядит так (наверное, что-то похожее можно и на D1.0 сделать):


Вчера проглядел, оказывается твой memoize не подерживает рекурсию, без этого он становится малоценным В общем нужно копать в сторону виртуальных функций http://gzip.rsdn.ru/Forum/Message.aspx?mid=2831064&amp;only=1
Автор: FR
Дата: 09.02.08
на D похоже по другому полноценный memoize не сделать.
Re[58]: C++0x начали урезать
От: FR  
Дата: 12.02.08 06:04
Оценка:
Здравствуйте, WolfHound, Вы писали:

E>>Вот, надоело сегодня целый день документацию писать, решил душу отвести. В самом примитивном виде memoize на D2.0 выглядит так (наверное, что-то похожее можно и на D1.0 сделать):

WH> Надеюсь ты сам понимаешь насколько это решение ущербно по сравнению с оригинальным макросом.

Кстати Немерлевсий макрос тоже коряв по сравнению с реализацией того же memoize на питоне например.
Но похоже для статически типизированного языка (правда не уверен насчет хаскеля) такое и вправду только на макросах можно соорудить. Кстати на D тоже это возможно, на текстовых миксинах которые по сути тоже макросы.
Re[2]: C++0x *крик души*
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 22.02.08 23:39
Оценка:
Здравствуйте, kov_serg, Вы писали:

Ругаться матом здесь не принято.
... << RSDN@Home 1.2.0 alpha rev. 800 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[3]: C++0x *крик души*
От: kov_serg Россия  
Дата: 23.02.08 00:53
Оценка:
Здравствуйте, AndrewVK, Вы писали:
Вроде не где не ругался. Видимо термин злое%&чий вызвал такую реакцию. Но это не мат.
А так обещаю впредь сдерживаться и исключит подобные выражения из постов.

Но суть такая простой модификацией, новое поколения языка получить не удасться. А что что щас делают тупиковый путь развития.
Re[10]: C++0x начали урезать
От: NikeByNike Россия  
Дата: 23.02.08 01:06
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В обом случае обещаю, что после осваения хотя бы одного ФЯ твои взгляды на программирование серьезно расширятся.


VD>Единственная проблема — С++ перестанет казаться самым подходящим языком для большинства применений.


А как у ОКамля с SSE и прочей оптимизацией?
Нужно разобрать угил.
Re[2]: C++0x *крик души*
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 23.02.08 03:13
Оценка:
Здравствуйте, kov_serg, Вы писали:

_> И еще непонимаю эту манию писать длинные namespace-ы с деситикратной вложенностью как в яве. Зачем?.


Просто придирка: в Яве нет вложенных пространств имён.
Ce n'est que pour vous dire ce que je vous dis.
Re[3]: C++0x *крик души*
От: Cyberax Марс  
Дата: 23.02.08 03:31
Оценка:
Здравствуйте, Don Reba, Вы писали:

_>> И еще непонимаю эту манию писать длинные namespace-ы с деситикратной вложенностью как в яве. Зачем?.

DR>Просто придирка: в Яве нет вложенных пространств имён.
Почему же? Есть.

Просто в Java нет _относительных_ пространств имён.
Sapienti sat!
Re[3]: C++0x *крик души*
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 23.02.08 13:23
Оценка:
Здравствуйте, kov_serg, Вы писали:

>>Просто придирка: в Яве нет вложенных пространств имён.

_>Посмотри исходники openOffice

Точки в названиях всего лишь условность. В Яве плоские упаковки. Вложенных пространств имён, как в С++, там нет. Собственно, в Яве действительно мало смысла так делать. В С++ вложенность позволяет ограничивать видимость имён слоями.
Ce n'est que pour vous dire ce que je vous dis.
Re[4]: C++0x *крик души*
От: kov_serg Россия  
Дата: 23.02.08 14:34
Оценка:
Здравствуйте, Don Reba, Вы писали:

DR>Точки в названиях всего лишь условность. В Яве плоские упаковки. Вложенных пространств имён, как в С++, там нет. Собственно, в Яве действительно мало смысла так делать. В С++ вложенность позволяет ограничивать видимость имён слоями.


Зачем? Зачем её делать слоями? Что бы мусор прятать под ковёр? Зачем так много лишних слоёв? Или наша цель что бы inteli-sence на правильно подсказывал? Но тогда нам надо знать куда ходить в какой складке спрятано то что нам надо. Да у виглядит убого a::b::c::d::e<a::b::c::e::f,a::b::c::e::g> z(a::b::c::d::z3);
Re[5]: C++0x *крик души*
От: Cyberax Марс  
Дата: 23.02.08 15:51
Оценка:
Здравствуйте, kov_serg, Вы писали:

DR>>Точки в названиях всего лишь условность. В Яве плоские упаковки. Вложенных пространств имён, как в С++, там нет. Собственно, в Яве действительно мало смысла так делать. В С++ вложенность позволяет ограничивать видимость имён слоями.

_>Зачем? Зачем её делать слоями? Что бы мусор прятать под ковёр? Зачем так много лишних слоёв? Или наша цель что бы inteli-sence на правильно подсказывал? Но тогда нам надо знать куда ходить в какой складке спрятано то что нам надо. Да у виглядит убого a::b::c::d::e<a::b::c::e::f,a::b::c::e::g> z(a::b::c::d::z3);
Тебе рассказать про using?

Namespace'ы нужны для предотвращения конфликта имён. Например, если не будет namespace'ов, то ты получишь конфликт, если подключишь thread из Boost'а и thread из Intel TBB.
Sapienti sat!
Re[3]: C++0x *крик души*
От: Cyberax Марс  
Дата: 23.02.08 16:22
Оценка:
Здравствуйте, kov_serg, Вы писали:

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

_>в виде _begin_thred и pthread_* -- это просто каменный век. Всё остальное это не стандарт это сторонние библиотеки!
И что?

_>Это еще поддержка модели памяти с обектами которые следят за количеством ссылок на них.

Так, что значат слова "модель памяти" ты не знаешь.

А указатели с подсчётом ссылок есть уже давно — boost::shared_ptr, boost::intrusive_ptr. В следующем Стандарте они тоже будут.

_>И синхронизация и обмен данными.

Синхронизация, естественно, будет в Стандарте.

_>И прозрачно описанный способ завершения потока.

Выход из верхней функции потока.

_>Например выкидывание исключения из функций синхронизации или ожидания.

??

_>Много всего. Чего приходиться или искать или заниматься велосипедостроением.

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

>>С точки зрения прикладного программиста — ничего особо серьезного.

_>Неужели. И как обычно решаются например обработка сигнала на завершение потока в C++, где поддерка TLS ?
http://en.wikipedia.org/wiki/C%2B%2B0x#Thread-local_storage ?

_>Самое прикольное что если в Linux у вас поток поделил на ноль то это просто катострофа а если обратился по NULL то конец света.

_>О какой многопоточности может идти речь. А между прочим все эти проблеммы можно решить именно комптлятором и не валить на ось что там нет нормальной поддержки SEH.
Как ты это решишь "компилятором"? Деление на ноль — это аппаратная ошибка, компилятор о ней ничего не знает. В Линуксе она вызывает соответствующий сигнал.

Если ты предлагаешь расставлять проверку на ноль перед каждым разыменованием к указателя — можешь идти лесом.

>>Указатели на члены класса — полезная вещь. Хотя сделали их и не очень красиво.

_>Некрасиво! да руки за такое отрывать надо
Кстати, предложи как сделать их красиво.

>>Затем же, зачем и в Java — убрать столкновения имён.

_>Да ну, а мужики то не знают. А откуда они появились столкновения имён? Почему нельзя сделать стандарт без этого убожества. А namespace-ы пользовать только когда действительно два отдельных конкретных велосипеда конфликтуют
Столкновения имён появились из-за того, что программисты не владеют телепатией. И два программиста вполне вполне могут решить использовать одно имя (даже внутри одного проекта).

Да, можно и без пространств имён обойтись — если делать префиксы к каждому имени. Ну как в SVN API, например: svn_get_status(..), svn_list_files(). Ничего не напоминает?

>>И что? Предлагается убрать все библитеки и писать всё целиком с нуля?

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

>> Написание компилятора С++ для платформы, на которой есть компилятор С — задача достаточно простая (спросите у Комо-С++). Естественно, если не портировать всякие RTTI и исключения.

_>Не смешите мои тапочки! Попробуй как-нибуть, я на тебя посмотрю. Языки C для микроконтроллеров почти все не способны переварить то что генерит Комо-С++ (болле того он еще и не бесплатный и распостронять ты его не сможешь).
Я не пробовал. Но компиляторы на базе Комо видел самолично. А еще есть LLVM-C, там на выходе вообще почти что ассемблер, записаный на С. Его вообще кто угодно скомпилирует.

Да, и я забыл про GCC — портирование его на новую архитектуру делается написание (буквально) пары файлов.

_>И потом Комо стандарт поддерживает не идеально.

Комо — это САМЫЙ СОВМЕСТИМЫЙ со Стандартом компилятор.

>>Это ты про "static void boost::thread::sleep(const xtime& xt);"? У нее, кстати, наносекундное разрешение на поддерживаемых системах...

_>какая нафиг разница какое у неё разрешение. почему нет функции double getSleepPrecision();? почему просто нельзя сделать простую и понятную функцию void sleep(double dt)? и потом не заморачиваясь писать sleep(25e-6); ???
Потому как с double'ом ты требуешь наличия сопроцессора или его эмуляции. Например, на MIPS'е где я использую boost::thread сопроцессора нет, а эмуляцию мне ставить не хочется. Функции getSleepPrecision() нет потому, что её нет в обычных threading API — в Windows и POSIX Threads гарантируется только, что sleep() будет работать не меньше указанного времени.

Но если так хочется "sleep(double seconds)" — возьми и напиши. Какие проблемы?

_>и нафига ей префикс boost::thread:: ?? это модно? или это придаёт чусво приобщения к вечности?

Про namespace'ы ты не знаешь, мы уже это установили.

_>код становиться короче и нагляднее если ей передавать не интервал, а конкретную дату?

Какую "конкретную дату", ты о чём?

_>Я об этом и говорю, и чем дальше тем хуже и хуже. Мы уже имеем убогий язык C# и C++.NET VisualBasic уже давно не Basic (это же был язык для начинающих, а щас это основной язык быдлокодерства для аспшного веба). слово VisualBasic можно считать ругательством.

Чем дальше — тем хуже, это как раз в твоём случае будет с мнимым разделением между слоями.

Нужен С++ с возможностью делать разметку отдельно от логики? Берём HTMLayout и используем. Какие проблемы-то? Зачем своё понимание "слоёв" навязывать всем остальным?
Sapienti sat!
Re[4]: C++0x *крик души*
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.02.08 18:18
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В следующем Стандарте

...
C>будет в Стандарте.
...
C>со Стандартом компилятор.

О как, с большой буквы. Это по типу как Библия?
... << RSDN@Home 1.2.0 alpha rev. 806 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[6]: C++0x *крик души*
От: kov_serg Россия  
Дата: 23.02.08 22:10
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Namespace'ы нужны для предотвращения конфликта имён. Например, если не будет namespace'ов, то ты получишь конфликт, если подключишь thread из Boost'а и thread из Intel TBB.


Я же говорю про стандарт. Я хочу нормальный стандарт, чтобы многопоточность поддерживалась языком единообразно независимо от платформы. Что бы мне небыло необходимости подключать OpenMPI, IntelTBB, boost.thread, glib и т.п.

почему нельзя сделать что то вида:

include "velosiped1" into namespace v1;
include "velosiped2" into namespace v2;
include <threads>

void fn() {
  sleep(1e-3);
  v1::sleep(10);
  v2::usleep(1000);
}
class A {
  public virtual stdcall abstart:
    int f1(int x,int y);
    int f2(int z);
    ...
};

Почему от подобная запись противоречит религии?
Re[7]: C++0x *крик души*
От: Cyberax Марс  
Дата: 23.02.08 22:29
Оценка:
Здравствуйте, kov_serg, Вы писали:

C>>Namespace'ы нужны для предотвращения конфликта имён. Например, если не будет namespace'ов, то ты получишь конфликт, если подключишь thread из Boost'а и thread из Intel TBB.

_>Я же говорю про стандарт. Я хочу нормальный стандарт, чтобы многопоточность поддерживалась языком единообразно независимо от платформы. Что бы мне небыло необходимости подключать OpenMPI, IntelTBB, boost.thread, glib и т.п.
Да какая разница! В Стандарт С++ всё запихать невозможно. И тогда придется писать: "mylib_point_2d" и "mylib_window" вместо нормального "point_2d" и "window". Так как шансы на конфликт имён с какой-нибудь бибилиотекой в будущем — почти 100%.

Да, и Стандарт никогда не заменит ВСЕ возможные варианты многопоточности. Это не нужно и невозможно.

_>Почему от подобная запись противоречит религии?

Потому как работать не будет. А тебе никто не мешает делать "using namespace blah" и писать без некрасивых "::".
Sapienti sat!
Re[4]: C++0x *крик души*
От: kov_serg Россия  
Дата: 23.02.08 22:51
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>А указатели с подсчётом ссылок есть уже давно — boost::shared_ptr, boost::intrusive_ptr. В следующем Стандарте они тоже будут.

если оно будет в том же виде что и в boost то нафиг не надо.

_>>И синхронизация и обмен данными.

C>Синхронизация, естественно, будет в Стандарте.
Слово естественно очень пугает.

_>>И прозрачно описанный способ завершения потока.

C>Выход из верхней функции потока.
....обещал не ругаться матом... ты посмотри на все службы в виндовз и на демоны в линухе. как устроен процесс завершения службы. и после этого ты хочеш сказать что все делают по стандарту? нафигаже они посылают запрос и ждут некоторое время? почему службы умудряются не отвечать минутами? неужели тяжело это было зарание предусмотреть?

_>>Например выкидывание исключения из функций синхронизации или ожидания.

C>??
Что непонятного, генерация исключения в потоку самый простой и очевидный способ его завершения для C++ c его объектами, разве не так?

_>>Много всего. Чего приходиться или искать или заниматься велосипедостроением.

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

>>>С точки зрения прикладного программиста — ничего особо серьезного.

_>>Неужели. И как обычно решаются например обработка сигнала на завершение потока в C++, где поддерка TLS ?
Где модификатор на уровне auto, register, static, volatile, где модификатор типа threadvar ???
C>http://en.wikipedia.org/wiki/C%2B%2B0x#Thread-local_storage ?
И еще докле мы будем в качестве констуктора и деструктора писать имя класса???? почему нельзя заредервировать имена типа ctor и dtor???

_>>Самое прикольное что если в Linux у вас поток поделил на ноль то это просто катострофа а если обратился по NULL то конец света.

_>>О какой многопоточности может идти речь. А между прочим все эти проблеммы можно решить именно комптлятором и не валить на ось что там нет нормальной поддержки SEH.
C>Как ты это решишь "компилятором"? Деление на ноль — это аппаратная ошибка, компилятор о ней ничего не знает. В Линуксе она вызывает соответствующий сигнал.
Ха. так что мешает компилятору генерить код который позволяет преобразовать сигнал в исключение??? ведь из обработчика сигнала мы спокойно можем передать управление в любую точку программы, в том числе и на вызов исключения. (единственное что gcc генерит очень забавный код который не позволяет генерить исключения где угодно). Если интересно могу подробно в деталях рассказать как сделать, если интересно.
C>Если ты предлагаешь расставлять проверку на ноль перед каждым разыменованием к указателя — можешь идти лесом.
Что я больной, если это всё аппаратно проверяется, а вот если нет то именно компилятор должен расставлять эти проверки.

>>>Указатели на члены класса — полезная вещь. Хотя сделали их и не очень красиво.

_>>Некрасиво! да руки за такое отрывать надо
C>Кстати, предложи как сделать их красиво.
Все велосипеды написанные на эту темы сводятся к написанию переходников, почему компилятор сам не может генерить подобное? может просто в стандарте этого нет.

>>>Затем же, зачем и в Java — убрать столкновения имён.

_>>Да ну, а мужики то не знают. А откуда они появились столкновения имён? Почему нельзя сделать стандарт без этого убожества. А namespace-ы пользовать только когда действительно два отдельных конкретных велосипеда конфликтуют
C>Столкновения имён появились из-за того, что программисты не владеют телепатией. И два программиста вполне вполне могут решить использовать одно имя (даже внутри одного проекта).
Отдельные проекты, да конешно. Но те кто делает стандарт, зачем им телепатия если есть интернет??? они что досих пор не смогли договориться?

C>Да, можно и без пространств имён обойтись — если делать префиксы к каждому имени. Ну как в SVN API, например: svn_get_status(..), svn_list_files(). Ничего не напоминает?

нет просто щас пространство имён есть как данность.
например надо писать
#include <string>
using namespace std
почему нельзя сделать наоборот
#include <string> into namespace std
???
а поумолчанию не включать namespace?
Да чусвствую щас приведёте кучу примеров почему нельзя, но все они связаны именно с тем что объектники так генеряться.

>>>И что? Предлагается убрать все библиотеки и писать всё целиком с нуля?

_>>Нет конешно. Просто констатирую факт. Но всё должно быть в языке естествено, а не так как щас. Приходится изучать кучу всего по большому счету совершенно ненужного. Что бы сделать элементарные вещи.
C>В любом другом языке так же. Нужно изучить кучу всякого ненужного, чтобы написать любую нормальную программу.
Я не спорю, что нужно долго учится, но метапрограмирование на templata-ах это не то чему надо учиться.

>>> Написание компилятора С++ для платформы, на которой есть компилятор С — задача достаточно простая ...

C>Я не пробовал. Но компиляторы на базе Комо видел самолично. А еще есть LLVM-C, там на выходе вообще почти что ассемблер, записаный на С. Его вообще кто угодно скомпилирует.
Ёмоё. так останется только компилятор комо, и все его баги будут включены в стандарт, ибо без них все имеющиеся библиотеки и программы работать не будут.

C>Да, и я забыл про GCC — портирование его на новую архитектуру делается написание (буквально) пары файлов.

Гон, не всё так просто. Попроюуй как-нибуть.

_>>И потом Комо стандарт поддерживает не идеально.

C> Комо — это САМЫЙ СОВМЕСТИМЫЙ со Стандартом компилятор.
Да, да конешно. И не поминай имя Комо C++ в суе.

>>>Это ты про "static void boost::thread::sleep(const xtime& xt);"? У нее, кстати, наносекундное разрешение на поддерживаемых системах...

_>>какая нафиг разница какое у неё разрешение. почему нет функции double getSleepPrecision();? почему просто нельзя сделать простую и понятную функцию void sleep(double dt)? и потом не заморачиваясь писать sleep(25e-6); ???
C>Потому как с double'ом ты требуешь наличия сопроцессора или его эмуляции. Например, на MIPS'е где я использую boost::thread сопроцессора нет, а эмуляцию мне ставить не хочется. Функции getSleepPrecision() нет потому, что её нет в обычных threading API — в Windows и POSIX Threads гарантируется только, что sleep() будет работать не меньше указанного времени.
Эмуляции испугался, а буст за собой таскаеш Волков бояться в лес не ходить. И потом есть числа с фикированной точкой. Всё же упирается в компилятор, а не в MIPS. Реализация double может быть разной не обязательно IEEE-шной. Да что бы преобразовать double в интервал для ожидания надо всего несколько инструкций пара андов и несколько сдвигов и сложений.
C>Но если так хочется "sleep(double seconds)" — возьми и напиши. Какие проблемы?
Так и сделаю. Но мне надо чтобы если я написал sleep(3.1536e7) он терпеливо ждал сигнала остановки потока и выкидывал исключение типа abort
Re[8]: C++0x *крик души*
От: kov_serg Россия  
Дата: 23.02.08 23:09
Оценка:
Здравствуйте, Cyberax, Вы писали:

_>>Почему от подобная запись противоречит религии?

C>Потому как работать не будет. А тебе никто не мешает делать "using namespace blah" и писать без некрасивых "::".

Да не мешает, я везде пишу using namespace.
Но ответь мне на простой вопрос почему в описании С++0x везде написано std::size_t ???
Неужели просто size_t это уже не достаточно готично?
ps: Когда то давно было задумано что sizeof(int)=sizeof(register) равен размеру регистра, а sizeof(long)=sizeof(void*) размеру указателя. но это не в тему...
Re[5]: C++0x *крик души*
От: Cyberax Марс  
Дата: 23.02.08 23:19
Оценка:
Здравствуйте, kov_serg, Вы писали:

C>>А указатели с подсчётом ссылок есть уже давно — boost::shared_ptr, boost::intrusive_ptr. В следующем Стандарте они тоже будут.

_>если оно будет в том же виде что и в boost то нафиг не надо.
Предложи лучший вариант...

C>>Синхронизация, естественно, будет в Стандарте.

_>Слово естественно очень пугает.
Я слабо представляю библиотеку для работы с многопоточностью без примитивов синхронизации. Ну кроме Erlang'а, разве что.

_>....обещал не ругаться матом... ты посмотри на все службы в виндовз и на демоны в линухе. как устроен процесс завершения службы. и после этого ты хочеш сказать что все делают по стандарту? нафигаже они посылают запрос и ждут некоторое время? почему службы умудряются не отвечать минутами? неужели тяжело это было зарание предусмотреть?

Причём тут процессы? Ты вообще понимаешь, что выход из потока и завершение программы с помощью управляющего сигнала — это вообще разные действия?

C>>??

_>Что непонятного, генерация исключения в потоку самый простой и очевидный способ его завершения для C++ c его объектами, разве не так?
Не так. Это неправильный подход.

_>>>Неужели. И как обычно решаются например обработка сигнала на завершение потока в C++, где поддерка TLS ?

_>Где модификатор на уровне auto, register, static, volatile, где модификатор типа threadvar ???
Слушай, ты вообще читаешь что тебе пишут?

A new thread-local storage duration (in addition to the existing static, dynamic and automatic) has been proposed for the next standard. Thread local storage will be indicated by the storage specifier thread_local.

Т.е. "thread_local SomeObject var;"

C>>http://en.wikipedia.org/wiki/C%2B%2B0x#Thread-local_storage ?

_>И еще докле мы будем в качестве констуктора и деструктора писать имя класса???? почему нельзя заредервировать имена типа ctor и dtor???
А зачем?

C>>Как ты это решишь "компилятором"? Деление на ноль — это аппаратная ошибка, компилятор о ней ничего не знает. В Линуксе она вызывает соответствующий сигнал.

_>Ха. так что мешает компилятору генерить код который позволяет преобразовать сигнал в исключение???
Из-за того, что это невозможно сделать корректно в общем случае.

_>ведь из обработчика сигнала мы спокойно можем передать управление в любую точку программы, в том числе и на вызов исключения. (единственное что gcc генерит очень забавный код который не позволяет генерить исключения где угодно). Если интересно могу подробно в деталях рассказать как сделать, если интересно.

Я прекрасно знаю как работает SEH, table-driven exceptions в GCC и почему асинхронные исключения в MSVC — плохая вещь.

C>>Если ты предлагаешь расставлять проверку на ноль перед каждым разыменованием к указателя — можешь идти лесом.

_>Что я больной, если это всё аппаратно проверяется, а вот если нет то именно компилятор должен расставлять эти проверки.
Ничего он не должен... Обращение по нулевому указателю и деление на ноль — это ОШИБКИ. Точно такая же, как обращение к удаленному объекту.

Их можно сделать штатным поведением, но это потребует слишком больших жертв в скорости и простоте C++.

C>>Кстати, предложи как сделать их красиво.

_>Все велосипеды написанные на эту темы сводятся к написанию переходников, почему компилятор сам не может генерить подобное? может просто в стандарте этого нет.
Переходники нужны для обхода слишком ограниченых указателей. Можно было бы сделать аналог делегатов в .NET, но это открывает банку с другими проблемами (с менеджментом памяти, в частности).

C>>Столкновения имён появились из-за того, что программисты не владеют телепатией. И два программиста вполне вполне могут решить использовать одно имя (даже внутри одного проекта).

_>Отдельные проекты, да конешно. Но те кто делает стандарт, зачем им телепатия если есть интернет??? они что досих пор не смогли договориться?
Мда. Даже комментировать не буду — смешно.

C>>Да, можно и без пространств имён обойтись — если делать префиксы к каждому имени. Ну как в SVN API, например: svn_get_status(..), svn_list_files(). Ничего не ...

_>а поумолчанию не включать namespace?
_>Да чусвствую щас приведёте кучу примеров почему нельзя, но все они связаны именно с тем что объектники так генеряться.
Нет. Есть такое хорошее правило — не делать опасные действия по умолчанию или неявно. Твой пример очень грубо этот принцип нарушает.

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

_>Я не спорю, что нужно долго учится, но метапрограмирование на templata-ах это не то чему надо учиться.
Почему? Полезная вещь. Например, у меня библиотека контейнеров написана на них. Она работает быстрее стандартных string/vector/list.

Да, в Стандарт её включить нельзя из-за того, что я её затачивал только под свои задачи.

C>>Я не пробовал. Но компиляторы на базе Комо видел самолично. А еще есть LLVM-C, там на выходе вообще почти что ассемблер, записаный на С. Его вообще кто угодно скомпилирует.

_>Ёмоё. так останется только компилятор комо, и все его баги будут включены в стандарт, ибо без них все имеющиеся библиотеки и программы работать не будут.
Почему?

C>>Да, и я забыл про GCC — портирование его на новую архитектуру делается написание (буквально) пары файлов.

_>Гон, не всё так просто. Попроюуй как-нибуть.
Пробовал как-то для экспериментов. См.: ftp://ftp.axis.se/pub/users/hp/pgccfd/pgccfd-0.5.pdf

Или просто посмотри простые md-файлы в GCC.

C>>Потому как с double'ом ты требуешь наличия сопроцессора или его эмуляции. Например, на MIPS'е где я использую boost::thread сопроцессора нет, а эмуляцию мне ставить не хочется. Функции getSleepPrecision() нет потому, что её нет в обычных threading API — в Windows и POSIX Threads гарантируется только, что sleep() будет работать не меньше указанного времени.

_>Эмуляции испугался, а буст за собой таскаеш
Те части Boost'а, которые я использую, имеют размер в килобайты.

_>И потом есть числа с фикированной точкой. Всё же упирается в компилятор, а не в MIPS. Реализация double может быть разной не обязательно IEEE-шной. Да что бы преобразовать double в интервал для ожидания надо всего несколько инструкций пара андов и несколько сдвигов и сложений.

Ага, чтобы пользователи double'а получили много неприятных сюрпризов.

Вот видишь, сколько твоё решение добавляет сложности, вместо простого указания наносекунд?

C>>Но если так хочется "sleep(double seconds)" — возьми и напиши. Какие проблемы?

_>Так и сделаю. Но мне надо чтобы если я написал sleep(3.1536e7) он терпеливо ждал сигнала остановки потока и выкидывал исключение типа abort
Ээ...? Ну напиши нужную функцию. Какие проблемы-то?
Sapienti sat!
Re[6]: C++0x *крик души*
От: kov_serg Россия  
Дата: 24.02.08 00:53
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Я слабо представляю библиотеку для работы с многопоточностью без примитивов синхронизации. Ну кроме Erlang'а, разве что.

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

C>Причём тут процессы? Ты вообще понимаешь, что выход из потока и завершение программы с помощью управляющего сигнала — это вообще разные действия?

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

_>>Что непонятного, генерация исключения в потоку самый простой и очевидный способ его завершения для C++ c его объектами, разве не так?

C>Не так. Это неправильный подход.
Нет это именно так. Только вызов исключения, других путей для C++ пока просто нет.

C>Т.е. "thread_local SomeObject var;"

+1 учту. особенно в ситуации что многопоточности в стандарте не будет.

C>>>http://en.wikipedia.org/wiki/C%2B%2B0x#Thread-local_storage ?

_>>И еще докле мы будем в качестве конструктора и деструктора писать имя класса???? почему нельзя зарезервировать имена типа ctor и dtor???
C>А зачем?
Сам подумай. Тебе надо поменять название класса. Тебе приходиться менять имена во многих местах. Просто нелогично и не удобно. И потом наличие пред деструктора и после конструктора особенно как виртуальных функций было бы замечательным явлением, но это мечты.

C>>>Как ты это решишь "компилятором"? Деление на ноль — это аппаратная ошибка, компилятор о ней ничего не знает. В Линуксе она вызывает соответствующий сигнал.

_>>Ха. так что мешает компилятору генерить код который позволяет преобразовать сигнал в исключение???
C>Из-за того, что это невозможно сделать корректно в общем случае.
Лошь и провакация. Можно.

_>>ведь из обработчика сигнала мы спокойно можем передать управление в любую точку программы, в том числе и на вызов исключения. (единственное что gcc генерит очень забавный код который не позволяет генерить исключения где угодно). Если интересно могу подробно в деталях рассказать как сделать, если интересно.

C>Я прекрасно знаю как работает SEH, table-driven exceptions в GCC и почему асинхронные исключения в MSVC — плохая вещь.
Да вы все сговорились. Вы похожи на тех кто делал dos extender-ы для 32bit protected mode. нет чтоб обработку прерывание передавать в пользовательский код они его обрабатывали сразу по приходу в отдельном стеке, чем связали руки не только себе.
MSVC плохая вешь, а table-driven exception просто замечательная. да вы сума сошли. выпиши в столбик недостатки и преимущества и ты удивишься.
Если после обработки подобных исключений в M$ всё работает, а в Linux выскакивает патрульное приложение и сообщает о скоропостижной смерти дочернего процесса и предлагает вам капнуть разработчикам или просто перезапустить процесс. Я вас непонимаю. Нормальная обработка исключений возможно в сколь угодно убогой оси.

C>Ничего он не должен... Обращение по нулевому указателю и деление на ноль — это ОШИБКИ. Точно такая же, как обращение к удаленному объекту.

Как вас переубедить. Что любое событие можно преобразовать в последовательность действий? В том числе и ошибки можно обрабатывать с помощью исключений.

C>Их можно сделать штатным поведением, но это потребует слишком больших жертв в скорости и простоте C++.

Ничего подобного. Никаких жертв, всё довольно просто и естественно. Да и потом кто бы говорил о простоте с таким стандартом.

...
C>Мда. Даже комментировать не буду — смешно.
тогда прокоментируй почему в стандарте есть char16_t char32_t, но нет int16, int32, int64 ???? или хотя бы std::float32_t ?

C>>>Да, можно и без пространств имён обойтись — если делать префиксы к каждому имени. Ну как в SVN API, например: svn_get_status(..), svn_list_files(). Ничего не ...

_>>а поумолчанию не включать namespace?
_>>Да чусвствую щас приведёте кучу примеров почему нельзя, но все они связаны именно с тем что объектники так генеряться.
C>Нет. Есть такое хорошее правило — не делать опасные действия по умолчанию или неявно. Твой пример очень грубо этот принцип нарушает.
да точно давайте на всё натянем колючую проволку и везде поставим капканы и растяжки и рассуём всё по наймспейсам что бы программист себя чуствовал как на минном поле на территории врага.

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

_>>Я не спорю, что нужно долго учится, но метапрограмирование на templata-ах это не то чему надо учиться.
C>Почему? Полезная вещь. Например, у меня библиотека контейнеров написана на них. Она работает быстрее стандартных string/vector/list.
C>Да, в Стандарт её включить нельзя из-за того, что я её затачивал только под свои задачи.
Очень удевлён столько ненужного уже есть в C++ и сколько обещают в C++0x

C>>>Я не пробовал. Но компиляторы на базе Комо видел самолично. А еще есть LLVM-C, там на выходе вообще почти что ассемблер, записаный на С. Его вообще кто угодно скомпилирует.

_>>Ёмоё. так останется только компилятор комо, и все его баги будут включены в стандарт, ибо без них все имеющиеся библиотеки и программы работать не будут.
C>Почему?
Монополия никчему хорошему не приводит.

C>Пробовал как-то для экспериментов. См.: ftp://ftp.axis.se/pub/users/hp/pgccfd/pgccfd-0.5.pdf

раз всё так просто помоги людям: http://propeller.wikispaces.com/Programming+in+C
C>Или просто посмотри простые md-файлы в GCC.
Скорее всего всё равно придётся писать на чистом C с ассемблерными вставками, как и раньше.

C>>>Потому как с double'ом ты требуешь наличия сопроцессора или его эмуляции. Например, на MIPS'е где я использую boost::thread сопроцессора нет, а эмуляцию мне ставить не хочется. Функции getSleepPrecision() нет потому, что её нет в обычных threading API — в Windows и POSIX Threads гарантируется только, что sleep() будет работать не меньше указанного времени.

_>>Эмуляции испугался, а буст за собой таскаеш
C>Те части Boost'а, которые я использую, имеют размер в килобайты.
Эмуляция double 2.5-4кб но это тебя безусловно пугает сильнее чем operator"Suffix". А вот double мы досих пор опасаемся. Пользуясь бустом бояться чисел с плавающей точкой. Просто фобия какая-то, аж смешно double и float был даже в C где нет апаратной поддержки применяется эмуляция и это всё в стандарте есть.

C>Ага, чтобы пользователи double'а получили много неприятных сюрпризов.

точно реализацию писали индусы и ты не опускаешся до таких сложных и непредсказуемых типов, а complex и quaternion придумали вообще еретики. Не понимающие как всё это тормозит

C>Вот видишь, сколько твоё решение добавляет сложности, вместо простого указания наносекунд?

нет не вижу.

!!повторюсь. Я просто наблюдаю как язык C++ движется в могилу. после 2009 года язык будет называться, хотя скорее всего не язык, а "Стандарт" C++1x, после 2019 C++2x и так далее
Но главное отключить фантазию и ни вкоем случае не пытаться предстаавить язык C++0x.NET
Re[7]: C++0x *крик души*
От: Cyberax Марс  
Дата: 24.02.08 02:52
Оценка:
Здравствуйте, kov_serg, Вы писали:

C>>Я слабо представляю библиотеку для работы с многопоточностью без примитивов синхронизации. Ну кроме Erlang'а, разве что.

_>Я не про библиотеку а про язык, что бы атомарные операции были частью языка. И потом язык программирования не обязан быть только алгоритмическим.
Когда мне говорят слова "алгоритмический язык [программирования]" — хочется в говорящего бросить тяжёлый предмет.

C>>Причём тут процессы? Ты вообще понимаешь, что выход из потока и завершение программы с помощью управляющего сигнала — это вообще разные действия?

_>Простая задача у тебя сотня потоков и тебе надо остановить половину, причем немедленно. и так что бы все созданные объекты умерли своей смертью. ваши действия? а если многопоточность есть в языке эта ситуация должна быть расписана.
Да никак этого не сделать корректно простыми способами. Н_И_К_А_К.

Банально:
void someFunction()
{
   char *c=(char*) heap_alloc(1123);
   //А вот тут прилетел пушной зверёк в виде исключения.
   ...
   heap_free(c);
}

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

Или еще хуже:
void someFunc()
{
   EnterCriticalSection(cs);
   //Упс...
   LeaveCriticalSection(cs);
}

//А потом в других потоках будем стоять и ждать бесконечности...


С асинхронными исключениями ровно та же проблема, кстати.

_>>>Что непонятного, генерация исключения в потоку самый простой и очевидный способ его завершения для C++ c его объектами, разве не так?

C>>Не так. Это неправильный подход.
_>Нет это именно так. Только вызов исключения, других путей для C++ пока просто нет.
А нет общего правильного способа для С++.

C>>А зачем?

_>Сам подумай. Тебе надо поменять название класса. Тебе приходиться менять имена во многих местах. Просто нелогично и не удобно. И потом наличие пред деструктора и после конструктора особенно как виртуальных функций было бы замечательным явлением, но это мечты.
Моя IDE умеет делать search&replace. В любом случае, придется менять название класса в реализациях методов.

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

C>>Из-за того, что это невозможно сделать корректно в общем случае.
_>Лошь и провакация. Можно.
Покажи код.

C>>Я прекрасно знаю как работает SEH, table-driven exceptions в GCC и почему асинхронные исключения в MSVC — плохая вещь.

_>Да вы все сговорились. Вы похожи на тех кто делал dos extender-ы для 32bit protected mode. нет чтоб обработку прерывание передавать в пользовательский код они его обрабатывали сразу по приходу в отдельном стеке, чем связали руки не только себе.
У меня сразу появилось уважение к создателям dos extender'ов. Так как они знают, что асинхронные события надо обрабатывать в отдельном контексте (банально, в пользовательском коде в момент исключения может быть разрушен указатель на стек).

_>MSVC плохая вешь, а table-driven exception просто замечательная. да вы сума сошли. выпиши в столбик недостатки и преимущества и ты удивишься.

Эээ... Может хватит с собой разговаривать?

_>Если после обработки подобных исключений в M$ всё работает, а в Linux выскакивает патрульное приложение и сообщает о скоропостижной смерти дочернего процесса и предлагает вам капнуть разработчикам или просто перезапустить процесс. Я вас непонимаю. Нормальная обработка исключений возможно в сколь угодно убогой оси.

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

C>>Ничего он не должен... Обращение по нулевому указателю и деление на ноль — это ОШИБКИ. Точно такая же, как обращение к удаленному объекту.

_>Как вас переубедить. Что любое событие можно преобразовать в последовательность действий? В том числе и ошибки можно обрабатывать с помощью исключений.
Ошибки программиста — нет. На них надо валиться как можно раньше и засылать bugreport.

C>>Их можно сделать штатным поведением, но это потребует слишком больших жертв в скорости и простоте C++.

_>Ничего подобного. Никаких жертв, всё довольно просто и естественно. Да и потом кто бы говорил о простоте с таким стандартом.
Покажи код...

C>>Мда. Даже комментировать не буду — смешно.

_>тогда прокоментируй почему в стандарте есть char16_t char32_t, но нет int16, int32, int64 ???? или хотя бы std::float32_t ?
std::float32_t не будет никогда — это бред. Аппаратура не умеет работать с плавающими числами произвольной точности.

int16/32/64 — есть. В виде short int, int, long long int.

C>>Нет. Есть такое хорошее правило — не делать опасные действия по умолчанию или неявно. Твой пример очень грубо этот принцип нарушает.

_>да точно давайте на всё натянем колючую проволку и везде поставим капканы и растяжки и рассуём всё по наймспейсам что бы программист себя чуствовал как на минном поле на территории врага.
Да, было бы неплохо, чтобы при любой ошибке я сразу бы получал в лоб при компиляции.

А для тех, кому не нравятся namespace'ы — рекомендую написать сложное приложение на JavaScript. Сколько бывает удовольствия...

C>>Почему? Полезная вещь. Например, у меня библиотека контейнеров написана на них. Она работает быстрее стандартных string/vector/list.

C>>Да, в Стандарт её включить нельзя из-за того, что я её затачивал только под свои задачи.
_>Очень удевлён столько ненужного уже есть в C++ и сколько обещают в C++0x
Это ты к чему?

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

C>>Почему?
_>Монополия никчему хорошему не приводит.
Я имею в виду — почему останется один Комо?

C>>Пробовал как-то для экспериментов. См.: ftp://ftp.axis.se/pub/users/hp/pgccfd/pgccfd-0.5.pdf

_>раз всё так просто помоги людям: http://propeller.wikispaces.com/Programming+in+C
Делать мне больше нечего, чем писать порт GCC для бесполезных контроллеров. Могу посоветовать взять LLVM и посмотреть в ней CBackend...

C>>Те части Boost'а, которые я использую, имеют размер в килобайты.

_>Эмуляция double 2.5-4кб но это тебя безусловно пугает сильнее чем operator"Suffix". А вот double мы досих пор опасаемся. Пользуясь бустом бояться чисел с плавающей точкой. Просто фобия какая-то, аж смешно double и float был даже в C где нет апаратной поддержки применяется эмуляция и это всё в стандарте есть.
Мне просто абсолютно не нужны лишние сущности на ровном месте. double/float, кстати, в С не был — он был в реализациях С, причем далеко не во всех.

Да, и корректная эмуляция плавающей точки занимает вовсе не 2кб. Эмулятор в linux-2.6.24/arch/mips/math-emu в скомпилированом виде занимает 73Кб. Только не надо говорить, что можно взять урезаный эмулятор.

C>>Ага, чтобы пользователи double'а получили много неприятных сюрпризов.

_> точно реализацию писали индусы и ты не опускаешся до таких сложных и непредсказуемых типов, а complex и quaternion придумали вообще еретики. Не понимающие как всё это тормозит
Нет. Есть такое понятие — контракт. Обычно программисты привыкли, что в double лежит IEEE-подобная плавучка. А тут окажется, что из-за того, что ты хочешь писать sleep(123d) — компилятор вдруг в определенных случаях начинает использовать фиксированую точку.

И как ты после этого можешь говорить, что программистам нужно много знать, чтобы писать программы?
Sapienti sat!
Re[7]: C++0x *крик души*
От: Cadet  
Дата: 24.02.08 07:56
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>почему нельзя сделать что то вида:


Скажи, а как разрулить такую ситуацию:

header1.h
namespace n1
{}


header2.h
#include "header1.h"

namespace n2
{}


source.cpp
#include "header2.h" into my_namespace1
#include "header1.h" into my_namespace2

/*...*/


Где у меня окажутся определения из namespace n1?
... << RSDN@Home 1.2.0 alpha rev. 788>>
Re[6]: C++0x *крик души*
От: Left2 Украина  
Дата: 24.02.08 09:55
Оценка:
C>Я прекрасно знаю как работает SEH, table-driven exceptions в GCC и почему асинхронные исключения в MSVC — плохая вещь.
А почему? Потому что SEH-и лазят в ядро?
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[7]: C++0x *крик души*
От: kov_serg Россия  
Дата: 24.02.08 11:28
Оценка:
Здравствуйте, Left2, Вы писали:

C>>Я прекрасно знаю как работает SEH, table-driven exceptions в GCC и почему асинхронные исключения в MSVC — плохая вещь.

L>А почему? Потому что SEH-и лазят в ядро?
Сами вы асинхронные. Деление на ноль и обращение к защиенной области памяти это СИНХРОННЫЕ события. И они не происходят из за событий из вне это вам не таймер и не NMI. SEH в ядро не лазит, более того все мета их возникновения в свойм коде компилятор может зарание виписать. Задача ядра обеспечить SEH, а не SEH-у лазить в ядро.
SEH должен быть реализован так чтоб ядра видно не было, но быть он должен.

Схема должна быть такой. Произошло исключение процессор перешел по idt в L0 выяснил чьё и сэмулировал в пользовательском стеке потока вызвавшего косяк вызов обработчика сигнала и потом передала управление потоку, а уже обработчик сигнала в обычном L3 вызывал исключение и то что ему кажется правильным. Где я не прав?
Где SEH в таком случае лазит в ядро???
Re[8]: Cyberax
От: kov_serg Россия  
Дата: 24.02.08 12:18
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Когда мне говорят слова "алгоритмический язык [программирования]" — хочется в говорящего бросить тяжёлый предмет.

Очень прискорбно. Разве он не такой? А когда вы слышите декларативный язык вы готовы биться головой ап стену?

C>>>Причём тут процессы? Ты вообще понимаешь, что выход из потока и завершение программы с помощью управляющего сигнала — это вообще разные действия?

_>>Простая задача у тебя сотня потоков и тебе надо остановить половину, причем немедленно. и так что бы все созданные объекты умерли своей смертью. ваши действия? а если многопоточность есть в языке эта ситуация должна быть расписана.
C>Да никак этого не сделать корректно простыми способами. Н_И_К_А_К.
Ха. это сейчас никак, почему это не предусмотреть, что бы программисты вместо Н_И_К_А_К говорили, элементарно, и дописывали одну две строчки?

C>Банально:

C>
C>void someFunction()
C>{
C>   char *c=(char*) heap_alloc(1123);
C>   //А вот тут прилетел пушной зверёк в виде исключения.
C>   ...
C>   heap_free(c);
C>}
C>

C>Получим утечку памяти. Причем этот код может быть внутри сторонней библиотеки.
Элементарно, неужели вам это не очевидно. Это решается именно стандартом и средствами компилятора.
void someFunction() {
   char *c=(char*)heap_alloc(1123); try {
   //А вот тут прилетел пушной зверёк в виде исключения. и нет проблемм
   ... 
   } finally {
     heap_free(c);
   }
}
или
void someFunction() {
   ptr<char> c=new char[1123];
   //А вот тут прилетел пушной зверёк в виде исключения. и нет проблемм
   ... 
}


C>Или еще хуже:

C>
C>void someFunc()
C>{
C>   EnterCriticalSection(cs);
C>   //Упс...
C>   LeaveCriticalSection(cs);
C>}
C>//А потом в других потоках будем стоять и ждать бесконечности...
C>

Ваши представления о генерации кода. Очень странные. Особенно тут. Просто не пиши так.
Почему нельзя встроить в язык конструкцию вида:
  lock(cs) {
    //action
  }

Теболее она есть во всех велосипедах примерно в таком виде:
struct Mutex;
struct Lock {
  Lock(Mutex *m) { if (m) m->enter(); }
  ~Lock() { if (m) m->leave(); }  
};
void someFunc() {
   { Lock __lock(mutex);
     // action
   }
}

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

C>С асинхронными исключениями ровно та же проблема, кстати.

Когда я говорил про асинхроныые исключения. !!!ТОЛЬКО СИНХРОННЫЕ!!! Поделил на ноль исключение, нарушил правила защиты исключение. Вызвал функцию ожидания или другую функцию которая может работать длительное время будь готов к исключению типа завершение потока. Чему это противоречит?

_>>>>Что непонятного, генерация исключения в потоку самый простой и очевидный способ его завершения для C++ c его объектами, разве не так?

C>>>Не так. Это неправильный подход.
_>>Нет это именно так. Только вызов исключения, других путей для C++ пока просто нет.
C>А нет общего правильного способа для С++.
? неужели. Так уж совсем нет, или никто не ищет?

C>>>А зачем?

_>>Сам подумай. Тебе надо поменять название класса. Тебе приходиться менять имена во многих местах. Просто нелогично и не удобно. И потом наличие пред деструктора и после конструктора особенно как виртуальных функций было бы замечательным явлением, но это мечты.
C>Моя IDE умеет делать search&replace. В любом случае, придется менять название класса в реализациях методов.
Ха ха ха. А еще твоя IDE умеет подсказывать код, и много еще чего. Причем тут IDE. Я про язык, а не про IDE. Кстати любовь к namespace-ам отчастья подпитывается именно эти самыми IDE c intelisence. Желание того чтоб он подсказывал то что хочется. В топку всё остальное лишбы было удобно и красиво в этом IDE.

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

C>>>Из-за того, что это невозможно сделать корректно в общем случае.
_>>Лошь и провакация. Можно.
C>Покажи код.
Посмотри HP c++ для Tru64

C>>>Я прекрасно знаю как работает SEH, table-driven exceptions в GCC и почему асинхронные исключения в MSVC — плохая вещь.

_>>Да вы все сговорились. Вы похожи на тех кто делал dos extender-ы для 32bit protected mode. нет чтоб обработку прерывание передавать в пользовательский код они его обрабатывали сразу по приходу в отдельном стеке, чем связали руки не только себе.
C>У меня сразу появилось уважение к создателям dos extender'ов. Так как они знают, что асинхронные события надо обрабатывать в отдельном контексте (банально, в пользовательском коде в момент исключения может быть разрушен указатель на стек).
Именно из за таких идиотов мы движемся не туда. 4 кольша в процессорах i386 и систему защиты сделали не для того чтобы усложнять жизнь, а для улучшения стабильности работы.
Правильным решением должно было. Обрабатывать прерывание в отдельном стеке, но не вызывать пользовательский код с привелегиями ядра для обработки исключения. (За это вы их тоже уважаете?) Надо было просто в пользовательском стеке на 3-ем уромне сделать эмуляцию возникновения прерывания как в обычном real86 и небыло бы никаких проблем.
И еще достали уже. Какое нафиг оно асинхронное. Асинхронное это прерывание по внешнему событию. А все отказы они синхронные!

C>MSVCшные асинхронные исключения маскируют ошибки. Они не могут работать на 100% корректно. Просто в большей части случаев программе везет, и не происходит повреждений.

Они СИНХРОННЫЕ!

C>Ошибки программиста — нет. На них надо валиться как можно раньше и засылать bugreport.

мдя. вот бы так ядро системы работало!

C>>>Их можно сделать штатным поведением, но это потребует слишком больших жертв в скорости и простоте C++.

_>>Ничего подобного. Никаких жертв, всё довольно просто и естественно. Да и потом кто бы говорил о простоте с таким стандартом.
C>Покажи код...
Какой именно код тебе показать?

C>std::float32_t не будет никогда — это бред. Аппаратура не умеет работать с плавающими числами произвольной точности.

C>int16/32/64 — есть. В виде short int, int, long long int.
Это не бред. два типа с плавающей точкой float и double есть уже давно.
А short,int и long всегда были привязаны к разрядности регистра и разрядности адреса процессора, для которого компилируется код.
sizeof(int)=8 pic16
sizeof(int)=16 x86
sizeof(int)=32 i386+ pm
sizeof(int)=64 x64
Каждый раз надо объявлять типы фиксированной разрядности, почему их не добавить в стандарт?

C>>>Нет. Есть такое хорошее правило — не делать опасные действия по умолчанию или неявно. Твой пример очень грубо этот принцип нарушает.

_>>да точно давайте на всё натянем колючую проволку и везде поставим капканы и растяжки и рассуём всё по наймспейсам что бы программист себя чуствовал как на минном поле на территории врага.
C>Да, было бы неплохо, чтобы при любой ошибке я сразу бы получал в лоб при компиляции.
Вы мазахист! Раскидайте по дому детских граблей и завяжите глаза...

C>А для тех, кому не нравятся namespace'ы — рекомендую написать сложное приложение на JavaScript. Сколько бывает удовольствия...

javascript -- это не язык. это именно script и в нем слишком много ограничений, он для мелких поделок и DHTML.

_>>Очень удевлён столько ненужного уже есть в C++ и сколько обещают в C++0x

C>Это ты к чему?
К тому, что много излишеств совершенно ненужных или реализованных совершенно противоестественным способом как в случае с шаблонами.

_>>Монополия никчему хорошему не приводит.

C>Я имею в виду — почему останется один Комо?
Потому что остальные вымрут.

C>Делать мне больше нечего, чем писать порт GCC для бесполезных контроллеров. Могу посоветовать взять LLVM и посмотреть в ней CBackend...

Гы. а говорил халява. А между прочим 8ядерный ширпотребный микроконтроллер для робототехники.

C>Мне просто абсолютно не нужны лишние сущности на ровном месте. double/float, кстати, в С не был — он был в реализациях С, причем далеко не во всех.

double/float это не лишние сущности. Неужели если ты оцениваешь время необходимое для окончания работы работы функции ты всё делаешь в целочисленной арифметике, или когда ты балансируеш трафик ты тоже пользуешь только int64? И потом операция sleep её просять притормозить выполнение, куда ты спешиш?
Откуда такая фобия?

C>Да, и корректная эмуляция плавающей точки занимает вовсе не 2кб. Эмулятор в linux-2.6.24/arch/mips/math-emu в скомпилированом виде занимает 73Кб. Только не надо говорить, что можно взять урезаный эмулятор.

Мдя. Ну нафига же мне эмулятор, всех команд сопроцессора. Арктангенс синус и логарифмы, если мне надо только перевод в целое, сложение и умножение? Ваши 73кб это от того что там много лишнего и ненужного, которое именно компилятор с линковщиком должны отбрасывать.

C>Нет. Есть такое понятие — контракт. Обычно программисты привыкли, что в double лежит IEEE-подобная плавучка. А тут окажется, что из-за того, что ты хочешь писать sleep(123d) — компилятор вдруг в определенных случаях начинает использовать фиксированую точку.

Есть такое понятие -- привычка. Вот вы так привыкли и не хотите смотреть на вещи иначе. Все эти окончания LL, D, UUL и т.п. это по большому счету бред.
надо было сразу пользоваться конструкторами классов типа
sleep(double(123.4));
sleep(fixed(123.53));
sleep(long(123));
sleep(int64(123));
а не
sleep(1);
sleep(1l);
sleep(1ll);
Просто у вас инертность большая и вы так привыкли. Но это безобразие.
Re[8]: C++0x *крик души*
От: kov_serg Россия  
Дата: 24.02.08 12:36
Оценка:
Здравствуйте, Cadet, Вы писали:

C>Скажи, а как разрулить такую ситуацию:


C>header1.h

C>
C>namespace n1
C>{}
C>


C>header2.h

C>
C>#include "header1.h"

C>namespace n2
C>{}
C>


C>source.cpp

C>
C>#include "header2.h" into my_namespace1
C>#include "header1.h" into my_namespace2

C>/*...*/
C>


C>Где у меня окажутся определения из namespace n1?

Это важно?

Я просто хотел сказать что такая любовь к избыточности совершенно никчему.
Re[9]: C++0x *крик души*
От: Cadet  
Дата: 24.02.08 13:23
Оценка:
Здравствуйте, kov_serg, Вы писали:

<skiped />

Все правильно, ты не получишь видимость чего-то, пока явно не запросишь необходимую тебе видимость. По умолчанию давать тебе абсолютно все, до чего можешь дотянуться — имхо не стоит, иначе моментально утонешь в сотнях вспомогательных функций/классов/typedef-ов и прочих радостях. Да и интеллисенс пожалей . Что надо — то и запрашивай. На проектах уровня HelloWorld — может это и напряжно. Я же предпочитаю писать не
#include <vector>
using namespace std;

а
#include <vector>
using std::vector;

а то и
#include <vector>
typedef std::vector<int> intVector;

потому что мне нужен вектор, возможно даже просто вектор интов, а не весь мусор из std, что как-то попал в хэдер вектора.
... << RSDN@Home 1.2.0 alpha rev. 788>>
Re[8]: C++0x *крик души*
От: jazzer Россия Skype: enerjazzer
Дата: 25.02.08 01:07
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Еще предлагаю ввести base0, base1, base2... А лучше сразу base(0), base(1)...

VE>Это для списка инициализации в случае множественного наследования, если кто не понял. Да и просто к базовым обращаться. Остается еще одна проблема — а если поменяют местами базовые в списке? Ну т.е. было public A, public B, а сделали public B, public A. Блин, тут есть над чем серьезно подумать!

Да что там думать — по алфавиту нада!
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[9]: C++0x *крик души*
От: anton_t Россия  
Дата: 25.02.08 04:51
Оценка:
Здравствуйте, jazzer, Вы писали:

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


VE>>Еще предлагаю ввести base0, base1, base2... А лучше сразу base(0), base(1)...

VE>>Это для списка инициализации в случае множественного наследования, если кто не понял. Да и просто к базовым обращаться. Остается еще одна проблема — а если поменяют местами базовые в списке? Ну т.е. было public A, public B, а сделали public B, public A. Блин, тут есть над чем серьезно подумать!

J>Да что там думать — по алфавиту нада!


При переименовании родительского класса тогда придётся учитывать: поменялся ли алфавитный порядок родительских классов или нет. Такие прикольные баги могут появиться
Re[9]: Cyberax
От: Cyberax Марс  
Дата: 25.02.08 18:35
Оценка:
Здравствуйте, kov_serg, Вы писали:

C>>Когда мне говорят слова "алгоритмический язык [программирования]" — хочется в говорящего бросить тяжёлый предмет.

_>Очень прискорбно. Разве он не такой? А когда вы слышите декларативный язык вы готовы биться головой ап стену?
Язык программирования может быть декларативным, функциональным, логическим, императивным. Единственное чем он не может быть — не алгоритмическим.

C>>Да никак этого не сделать корректно простыми способами. Н_И_К_А_К.

_>Ха. это сейчас никак, почему это не предусмотреть, что бы программисты вместо Н_И_К_А_К говорили, элементарно, и дописывали одну две строчки?
Ну допиши...

_>
_>void someFunction() {
_>   char *c=(char*)heap_alloc(1123); try {
_>   //А вот тут прилетел пушной зверёк в виде исключения. и нет проблемм
_>   ... 
_>   } finally {
_>     heap_free(c);
_>   }
_>}
_>или
_>void someFunction() {
_>   ptr<char> c=new char[1123];
_>   //А вот тут прилетел пушной зверёк в виде исключения. и нет проблемм
_>   ... 
_>}
_>

И каким образом компилятор догадается, что ему нужно достроить try..finally?
Hint: эта задача неразрешима в принципе

Ну и я уж не говорю про то, что это всё может быть во внешней бинарной библиотеке, написаной на Objective C.

C>>
C>>void someFunc()
C>>{
C>>   EnterCriticalSection(cs);
C>>   //Упс...
C>>   LeaveCriticalSection(cs);
C>>}
C>>//А потом в других потоках будем стоять и ждать бесконечности...
C>>

_>Ваши представления о генерации кода. Очень странные. Особенно тут. Просто не пиши так.
Какая генерация кода? Ты о чём вообще?

Этот код может быть в библиотеке на чистом С. Или он может быть специально написан с использованием ручных вызовов функции.

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

C>>С асинхронными исключениями ровно та же проблема, кстати.

_>Когда я говорил про асинхроныые исключения. !!!ТОЛЬКО СИНХРОННЫЕ!!! Поделил на ноль исключение, нарушил правила защиты исключение. Вызвал функцию ожидания или другую функцию которая может работать длительное время будь готов к исключению типа завершение потока. Чему это противоречит?
Всему. См. выше.

C>>А нет общего правильного способа для С++.

_>? неужели. Так уж совсем нет, или никто не ищет?
Нет, не будет, и нет смысла искать.

C>>Моя IDE умеет делать search&replace. В любом случае, придется менять название класса в реализациях методов.

_>Ха ха ха. А еще твоя IDE умеет подсказывать код, и много еще чего. Причем тут IDE. Я про язык, а не про IDE. Кстати любовь к namespace-ам отчастья подпитывается именно эти самыми IDE c intelisence. Желание того чтоб он подсказывал то что хочется. В топку всё остальное лишбы было удобно и красиво в этом IDE.
Это же ты что-то начал мямлить про ctor/dtor. Тольк зачем это нужно? Для облегчения cut&paste?

C>>Покажи код.

_>Посмотри HP c++ для Tru64
Файлы, строки?

C>>У меня сразу появилось уважение к создателям dos extender'ов. Так как они знают, что асинхронные события надо обрабатывать в отдельном контексте (банально, в пользовательском коде в момент исключения может быть разрушен указатель на стек).

_>Именно из за таких идиотов мы движемся не туда.
Тут вообще-то на личности не переходят...

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

Угу, поэтому эти кольца пошли лесом во всех основных операционках. Осталось только нулевое и третее кольца.

_>Правильным решением должно было. Обрабатывать прерывание в отдельном стеке, но не вызывать пользовательский код с привелегиями ядра для обработки исключения. (За это вы их тоже уважаете?) Надо было просто в пользовательском стеке на 3-ем уромне сделать эмуляцию возникновения прерывания как в обычном real86 и небыло бы никаких проблем.

Угу. И на каждое прерывание щёлкать контекстами (а это МЕДЛЕННО). Ой как этому драйверы обрадуются...

_>И еще достали уже. Какое нафиг оно асинхронное. Асинхронное это прерывание по внешнему событию. А все отказы они синхронные!

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

C>>MSVCшные асинхронные исключения маскируют ошибки. Они не могут работать на 100% корректно. Просто в большей части случаев программе везет, и не происходит повреждений.

_>Они СИНХРОННЫЕ!
http://msdn2.microsoft.com/en-us/library/1deeycx5.aspx — grep по слову "async"...

C>>Ошибки программиста — нет. На них надо валиться как можно раньше и засылать bugreport.

_>мдя. вот бы так ядро системы работало!
Оно так и работает...

_>>>Ничего подобного. Никаких жертв, всё довольно просто и естественно. Да и потом кто бы говорил о простоте с таким стандартом.

C>>Покажи код...
_>Какой именно код тебе показать?
"Абсолютно правильной(tm)" обработки исключений.

C>>std::float32_t не будет никогда — это бред. Аппаратура не умеет работать с плавающими числами произвольной точности.

C>>int16/32/64 — есть. В виде short int, int, long long int.
_>Это не бред. два типа с плавающей точкой float и double есть уже давно.
Ну да. А где же у нас float64 и double128?

_>Каждый раз надо объявлять типы фиксированной разрядности, почему их не добавить в стандарт?

http://en.wikipedia.org/wiki/C%2B%2B0x#Type_long_long_int

C>>Да, было бы неплохо, чтобы при любой ошибке я сразу бы получал в лоб при компиляции.

_>Вы мазахист! Раскидайте по дому детских граблей и завяжите глаза...
Есть мааааленькая разница. Ошибки компиляции указывают мне на ошибки в моём коде. Чем больше компилятор их найдет — тем лучше.

Расставление граблей — это как раз то, что вы любите делать.

C>>А для тех, кому не нравятся namespace'ы — рекомендую написать сложное приложение на JavaScript. Сколько бывает удовольствия...

_>javascript -- это не язык. это именно script и в нем слишком много ограничений, он для мелких поделок и DHTML.
Кхм... Google Mail?

C>>Я имею в виду — почему останется один Комо?

_>Потому что остальные вымрут.
С чего бы?

C>>Делать мне больше нечего, чем писать порт GCC для бесполезных контроллеров. Могу посоветовать взять LLVM и посмотреть в ней CBackend...

_>Гы. а говорил халява. А между прочим 8ядерный ширпотребный микроконтроллер для робототехники.
Оно не сложно, где-то на неделю работы. Недели лишнего времени у меня нет.

_>double/float это не лишние сущности. Неужели если ты оцениваешь время необходимое для окончания работы работы функции ты всё делаешь в целочисленной арифметике, или когда ты балансируеш трафик ты тоже пользуешь только int64? И потом операция sleep её просять притормозить выполнение, куда ты спешиш?

double/float — именно ЛИШНИЕ сущности в твоём примере. Они НИЧЕГО не дают по сравнению с указанием наносекунд. В смысле АБСОЛЮТНО ничего.Зато требуют подключение всего механизма работы с плавающей точкой.

Причём тут баллансировка траффика — мне вообще непонятно.

_>Мдя. Ну нафига же мне эмулятор, всех команд сопроцессора. Арктангенс синус и логарифмы, если мне надо только перевод в целое, сложение и умножение? Ваши 73кб это от того что там много лишнего и ненужного, которое именно компилятор с линковщиком должны отбрасывать.

Я же просил — не говорить про урезаный эмулятор... Это очередные сложности на пустом месте.

_>Есть такое понятие -- привычка. Вот вы так привыкли и не хотите смотреть на вещи иначе. Все эти окончания LL, D, UUL и т.п. это по большому счету бред.

Вот вашу привычку и лучше ломать. Нефиг ваши измышления выдавать за истину в последней инстанции.

_>Просто у вас инертность большая и вы так привыкли. Но это безобразие.

Нет, просто вы не писали реальных больших систем. Это сразу видно.
Sapienti sat!
Re[10]: Cyberax
От: kov_serg Россия  
Дата: 26.02.08 00:52
Оценка:
Здравствуйте, Cyberax, Вы писали:

_>>
_>>void someFunction() {
_>>   char *c=(char*)heap_alloc(1123); try {
_>>   //А вот тут прилетел пушной зверёк в виде исключения. и нет проблемм
_>>   ... 
_>>   } finally {
_>>     heap_free(c);
_>>   }
_>>}
_>>или
_>>void someFunction() {
_>>   ptr<char> c=new char[1123];
_>>   //А вот тут прилетел пушной зверёк в виде исключения. и нет проблемм
_>>   ... 
_>>}
_>>

C>И каким образом компилятор догадается, что ему нужно достроить try..finally?
Вообще-то C++ компилятор это уже делает. При вызове исключения он последовательно вызывает деструкторы созданных объектов.
C>Hint: эта задача неразрешима в принципе
слово "это" — очень не хорошее слово. в данном контексте оно потеряло значимость.

C>Ну и я уж не говорю про то, что это всё может быть во внешней бинарной библиотеке, написаной на Objective C.

Любая проблемма тоже может быть решена, хотя не обязательно точно и полно:
Например при вызове внешней библиотеке, в потоке можно менять поведение обработчика исключений,
принципе можно следить за ресурсами выделяемыми этой сторонней библиотекой.
Более того эту библиотеку можно запускать, как бы изолировано, что бы имелась возможность
освободить всё что зависло в памяти, вплоть до запуска в отдельном процессе.

C>>>
C>>>void someFunc()
C>>>{
C>>>   EnterCriticalSection(cs);
C>>>   //Упс...
       if (something) return; // -- упс 
C>>>   //Упс...
C>>>   LeaveCriticalSection(cs);
C>>>}
C>>>//А потом в других потоках будем стоять и ждать бесконечности...
C>>>

_>>Ваши представления о генерации кода. Очень странные. Особенно тут. Просто не пиши так.
C>Какая генерация кода? Ты о чём вообще?
О том что в таком коде изначально заложена возможнось пролететь. В идеале для такиз случаев нужна конструкция в языке вида:
  {
    EnterCriticalSection(cs); scope_leave { LeaveCriticalSection(cs); };
    //Упс...
  }

C>Этот код может быть в библиотеке на чистом С. Или он может быть специально написан с использованием ручных вызовов функции.
  {
    unsafe { // меняем способ реагирования на исключения, и метод слежения за ресурсами
      lib.betta(params);
    }
  }


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

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

C>>>А нет общего правильного способа для С++.

_>>? неужели. Так уж совсем нет, или никто не ищет?
C>Нет, не будет, и нет смысла искать.
Да мы все умрём. Но сложить лапки и не рапаться это не наш метод. Если вы не видите смысла искать и уже доказали невозможность, то вечная вам память.

C>>>Моя IDE умеет делать search&replace. В любом случае, придется менять название класса в реализациях методов.

_>>Ха ха ха. А еще твоя IDE умеет подсказывать код, и много еще чего. Причем тут IDE. Я про язык, а не про IDE. Кстати любовь к namespace-ам отчастья подпитывается именно эти самыми IDE c intelisence. Желание того чтоб он подсказывал то что хочется. В топку всё остальное лишбы было удобно и красиво в этом IDE.
C>Это же ты что-то начал мямлить про ctor/dtor. Тольк зачем это нужно? Для облегчения cut&paste?
Нет. Просто большая избыточность. Вообще-то хочется повысить читабельнось и нагляднось, а не просто облехчать работу в какомно там IDE.
// .h
class SampleClassWithHumanReadableName : public BaseClass {
public:
    SampleClassWithHumanReadableName();
    ~SampleClassWithHumanReadableName();
};
// .cpp
SampleClassWithHumanReadableName::SampleClassWithHumanReadableName() {}
SampleClassWithHumanReadableName::~SampleClassWithHumanReadableName() {}

vs

// .hh
class SampleClassWithHumanReadableName : public BaseClass {
public:
    ctor();
    dtor();
};
// .cc
namespace SampleClassWithHumanReadableName {
  ctor() {}
  dtor() {}
}
[code]
Коряво конешно. Но идея такая, зачем много раз дублировать одно и тоже особенно если это класс большой вложенности a::b::c::d

C>>>Покажи код.
_>>Посмотри HP c++ для Tru64
C>Файлы, строки?
/usr/ccs/lib/cmplrs/cc/libexc.a - exception handling library
/usr/include/excpt.h 
/usr/include/pdsc.h 
/usr/include/signal.h 

Тут:
http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51_HTML/ARH9MBTE/VNTPRCSS.HTM#exc-sig-hand-coexistence
http://www.camk.edu.pl/doc/ccc/Programmers_Guide/XCPTCHPX.HTM
функция exc_raise_signal_exception

Выглядит примерно так:
[code]
#include <excpt.h> 
#include <stdio.h> 
#include <signal.h>
struct sigaction foo={ (void(*)(int))exc_raise_signal_exception,0,0 };
double x,y=0; 
void main() {
    sigaction(SIGFPE,&foo,0);
    sigaction(SIGSEGV,&foo,0);
    try {
        x=x/y;
        printf("exception not raised\n");
    } catch(...) {
        printf("exception raised correctly\n");
    }
}


C>>>У меня сразу появилось уважение к создателям dos extender'ов. Так как они знают, что асинхронные события надо обрабатывать в отдельном контексте (банально, в пользовательском коде в момент исключения может быть разрушен указатель на стек).

_>>Именно из за таких идиотов мы движемся не туда.
C>Тут вообще-то на личности не переходят...
Я и не перехожу. Просто обработака прерываний в dos-extender-ах убила возможность многопоточность в них на корню.

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

C>Угу, поэтому эти кольца пошли лесом во всех основных операционках. Осталось только нулевое и третее кольца.
Да есть такая фигня. Хотя так крависво было задумано только ядро на 0 уровне, на 1-ом система, на 2-ом драйвера и только на 3-ем всякий прикладной и глючный софт.

_>>Правильным решением должно было. Обрабатывать прерывание в отдельном стеке, но не вызывать пользовательский код с привелегиями ядра для обработки исключения. (За это вы их тоже уважаете?) Надо было просто в пользовательском стеке на 3-ем уромне сделать эмуляцию возникновения прерывания как в обычном real86 и небыло бы никаких проблем.

C>Угу. И на каждое прерывание щёлкать контекстами (а это МЕДЛЕННО). Ой как этому драйверы обрадуются...
Ха. именно так и происходит, но контекстами щелкает проц. Меделено не медленно, но так бы было правильно и позволило развиваться. А так похоронили заживо.

_>>И еще достали уже. Какое нафиг оно асинхронное. Асинхронное это прерывание по внешнему событию. А все отказы они синхронные!

C>"Асинхронное" означет "без контроля со стороные прикладного кода". Т.е. для прикладного кода оно может случится в любой момент.
Очень удивил. Деление на ноль происходит только когда ты вызываеш операцию деления! Так же и с обращением к защищенной памяти.
Конешно есть т другие события прерывание по отладке например

C>>>MSVCшные асинхронные исключения маскируют ошибки. Они не могут работать на 100% корректно. Просто в большей части случаев программе везет, и не происходит повреждений.

_>>Они СИНХРОННЫЕ!
C>http://msdn2.microsoft.com/en-us/library/1deeycx5.aspx — grep по слову "async"...
Это опечатка, напиши им пусть исправят Они называют общий вид исключений поэтому так и написали. Асинхронный значит от внешнего источника, а синхронны это сама программа. Например out of bouds, access violation, divide by zero, overflow -- это всё синхнонные события. Выполнил условие получил исключение.
if (cond) throw;
Somewhat related with the concept of checked exceptions is exception synchronity. Synchronous exceptions happen at a specific program statement whereas asynchronous exceptions can raise practically anywhere.[9][10] It follows that asynchronous exception handling can't be required by the compiler. They are also difficult to program with. Examples of naturally asynchronous events include pressing Ctrl-C to interrupt a program, and receiving a signal such as "stop" or "suspend" from another thread of execution.

Programming languages typically deal with this by limiting asynchronity, for example Java has lost thread stopping and resuming.[11] Instead, there can be semi-asynchronous exceptions that only raise in suitable locations of the program or synchronously.

http://en.wikipedia.org/wiki/Exception_handling

C>>>Ошибки программиста — нет. На них надо валиться как можно раньше и засылать bugreport.

_>>мдя. вот бы так ядро системы работало!
C>Оно так и работает...
Что то я не помню чтобы ядро сисемы писали на С++. Видел только на C.

_>>>>Ничего подобного. Никаких жертв, всё довольно просто и естественно. Да и потом кто бы говорил о простоте с таким стандартом.

C>>>Покажи код...
_>>Какой именно код тебе показать?
C>"Абсолютно правильной(tm)" обработки исключений.
Вообще "Абсолютно правильной(tm)" уже торговая марка есть?
Незнаю как насчет абсолютно правильного, но как вполне приемлиа схема така для каждого отдельного потока в приложении это обработка исключений не должна отличаться от ситуации если бы это поток работал один в реальном режиме. т.е. он ничего не должен знать что происходило в ядре системы. Примером может служить window-ый SEH вполне добротно сделано. Единственное что переполнение стека надо обрабатывать отдельно. А асинхронные события по схеме как работают прерывания. Только разница в том что они эмулируются системой, т.е. ядро вписывает в стек адресс возврата и флаги и передаёт управление обработчику пользователя.

C>>>std::float32_t не будет никогда — это бред. Аппаратура не умеет работать с плавающими числами произвольной точности.

Я не говорю об произвольной точность, но float32 и float64 -- это стандарт для большинства процессоров имеющих FPU. Есть конечно суперскалярные у которых вектора из float32.
C>>>int16/32/64 — есть. В виде short int, int, long long int.
_>>Это не бред. два типа с плавающей точкой float и double есть уже давно.
C>Ну да. А где же у нас float64 и double128?
а нафига тебе double128? я говорю об стандартных типах, которые можно встерить в файлах данных.
typedef float float32;
typedef double float64;
//typedef long double float80; // хотя такого уже больше нет хотя в x86 регистры сопроцессора именно такие
Имеется ввиду что иногда нужны типы данных не максимально быстро работающие на данном процессоре, а именно фиксированных параметров.

_>>Каждый раз надо объявлять типы фиксированной разрядности, почему их не добавить в стандарт?

C>http://en.wikipedia.org/wiki/C%2B%2B0x#Type_long_long_int
Я же тебе говорю что на 64бит системах твой long long int будет не 64бит а в два раза больше. (Более того на практике в разных компиляторах имеются разногласия на это счет).
Все подключат хедаы с #if sizeof(int)=4 ... , #if GCC long long... #if VC __int64...

C>>>Да, было бы неплохо, чтобы при любой ошибке я сразу бы получал в лоб при компиляции.

_>>Вы мазахист! Раскидайте по дому детских граблей и завяжите глаза...
C>Есть мааааленькая разница. Ошибки компиляции указывают мне на ошибки в моём коде. Чем больше компилятор их найдет — тем лучше.
Да есть разница, компилятор вам ничего не скажет -- это ошибки runtime! (входных данных). Лучше бы он мог говорить контекст ошибки с возможностью отката назад, хотя это больше к отладной информации, которую тоже генерит компилятор с линковщиком.

C>>>А для тех, кому не нравятся namespace'ы — рекомендую написать сложное приложение на JavaScript. Сколько бывает удовольствия...

_>>javascript -- это не язык. это именно script и в нем слишком много ограничений, он для мелких поделок и DHTML.
C>Кхм... Google Mail?
да и на бейсике можно программы писать. и что? дело в другом: одна и таже программа написаная на разных языках требует разный уровень затрат, и её будут иметь свои "профессиональные" проблеммы, которые определяются именно языком и тем способом которым программист опходит недостатки этого языка.

_>>Мдя. Ну нафига же мне эмулятор, всех команд сопроцессора. Арктангенс синус и логарифмы, если мне надо только перевод в целое, сложение и умножение? Ваши 73кб это от того что там много лишнего и ненужного, которое именно компилятор с линковщиком должны отбрасывать.

C>Я же просил — не говорить про урезаный эмулятор... Это очередные сложности на пустом месте.
Не понимаю, у вас все программы не используют float и double?

_>>Есть такое понятие -- привычка. Вот вы так привыкли и не хотите смотреть на вещи иначе. Все эти окончания LL, D, UUL и т.п. это по большому счету бред.

C>Вот вашу привычку и лучше ломать. Нефиг ваши измышления выдавать за истину в последней инстанции.
Я такого никогда не говорил.

_>>Просто у вас инертность большая и вы так привыкли. Но это безобразие.

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

ps: Чаще смотрите в ночное небо, там звёзды, и они прекрасны...
Re[11]: Cyberax
От: Cyberax Марс  
Дата: 26.02.08 01:42
Оценка:
Здравствуйте, kov_serg, Вы писали:

C>>И каким образом компилятор догадается, что ему нужно достроить try..finally?

_>Вообще-то C++ компилятор это уже делает. При вызове исключения он последовательно вызывает деструкторы созданных объектов.
Ещё раз меееедленно: есть cleanup-действия которые, НЕ производятся деструкторами.

C>>Ну и я уж не говорю про то, что это всё может быть во внешней бинарной библиотеке, написаной на Objective C.

_>Любая проблемма тоже может быть решена, хотя не обязательно точно и полно:
_>Например при вызове внешней библиотеке, в потоке можно менять поведение обработчика исключений,
Угу. Как? У тебя есть dll/lib. Что ты там менять будешь?

А если эта библиотека делает callback в твой код?

_>принципе можно следить за ресурсами выделяемыми этой сторонней библиотекой.

Как?

_>Более того эту библиотеку можно запускать, как бы изолировано, что бы имелась возможность

Как?

_>освободить всё что зависло в памяти, вплоть до запуска в отдельном процессе.

Угу, спасибо. С такими предложениями — в лес.

C>>>>
C>>>>void someFunc()
C>>>>{
C>>>>   EnterCriticalSection(cs);
C>>>>   //Упс...
_>       if (something) return; // -- упс

А нету "if(something) return". Код портировали с чистого С и оставили всё как было.

_>О том что в таком коде изначально заложена возможнось пролететь. В идеале для такиз случаев нужна конструкция в языке вида:

Да я не спорю. В идеальном мире вообще всё было бы хорошо. Тот код, который я написал — СУЩЕСТВУЕТ КАК ОБЪЕКТИВНАЯ РЕАЛЬНОСТЬ.

Далее, есть совершенно валидный код, который свалится с асинхронными исключениями:
class list
{
   list *next, *prev;
 
   void add_before(list *elem)
   {
      prev->next=elem;
      //Тут вылетает птичка.
      elem->next=this;
      elem->prev=prev;
      prev=elem;
   }

   ~list()
   {
      //Chain deletion
      if (next) delete next;
   }
}

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

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

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

_>Нет конешно. Я предлагаю поменять подход к написанию новых программ.
Идёшь в лес.

_>Да мы все умрём. Но сложить лапки и не рапаться это не наш метод. Если вы не видите смысла искать и уже доказали невозможность, то вечная вам память.

Сначала рекомендую изучить предмет.

_>[code]

_>// .h
_>class SampleClassWithHumanReadableName : public BaseClass {
_>public:
_> SampleClassWithHumanReadableName();
_> ~SampleClassWithHumanReadableName();
_>};
_>// .cpp
_>SampleClassWithHumanReadableName::SampleClassWithHumanReadableName() {}
_>SampleClassWithHumanReadableName::~SampleClassWithHumanReadableName() {}

_>vs


_>// .hh

_>class SampleClassWithHumanReadableName : public BaseClass {
_>public:
_> ctor();
_> dtor();
_>};
_>// .cc
_>namespace SampleClassWithHumanReadableName {
_> ctor() {}
_> dtor() {}
_>}
_>[code]
_>Коряво конешно. Но идея такая, зачем много раз дублировать одно и тоже особенно если это класс большой вложенности a::b::c::d
Читаемость лучше в первом случае. Так как в исходнике строк хотя бы на 500 придётся очень долго искать чего же мы сейчас реализуем.

_>Тут:

_>http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51_HTML/ARH9MBTE/VNTPRCSS.HTM#exc-sig-hand-coexistence
_>http://www.camk.edu.pl/doc/ccc/Programmers_Guide/XCPTCHPX.HTM
_>функция exc_raise_signal_exception
Угу, аналог SEHа. Почему он не работает — см. пример выше.

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

C>>Угу, поэтому эти кольца пошли лесом во всех основных операционках. Осталось только нулевое и третее кольца.
_>Да есть такая фигня. Хотя так крависво было задумано только ядро на 0 уровне, на 1-ом система, на 2-ом драйвера и только на 3-ем всякий прикладной и глючный софт.
Всё красиво на бумаге, да забыли про овраги...

Даже для NT с её IRQL оказались колечки не нужны.

C>>Угу. И на каждое прерывание щёлкать контекстами (а это МЕДЛЕННО). Ой как этому драйверы обрадуются...

_>Ха. именно так и происходит, но контекстами щелкает проц. Меделено не медленно, но так бы было правильно и позволило развиваться. А так похоронили заживо.
И что, что процессор меняет контексты. Это всё равно медленно, и с каждым годом становится всё медленнее.

Есть такая замечательная микроядерная OS QNX. Там ядро занимает что-то около 30 килобайт рукописного ассемблера, а все драйверы работают в отдельных процессах. В 90-е годы в QNXе были отдельные серверы IO, графики, сети. Где-то в 2003-м году их объединили — так как тормозило всё слишком из-за избыточных переключений контекстов.

_>>>И еще достали уже. Какое нафиг оно асинхронное. Асинхронное это прерывание по внешнему событию. А все отказы они синхронные!

C>>"Асинхронное" означет "без контроля со стороные прикладного кода". Т.е. для прикладного кода оно может случится в любой момент.
_>Очень удивил. Деление на ноль происходит только когда ты вызываеш операцию деления! Так же и с обращением к защищенной памяти.
Защищенная память обрабатывается системой, для прикладного приложения оно вообще незаметно (если не стараться). Ошибка деления на ноль для прикладного приложения тоже происходит "незаметно" — в момент, когда оно его не ожидает.

_>Конешно есть т другие события прерывание по отладке например

Точно так же.

_>>>Они СИНХРОННЫЕ!

C>>http://msdn2.microsoft.com/en-us/library/1deeycx5.aspx — grep по слову "async"...
_>Это опечатка, напиши им пусть исправят Они называют общий вид исключений поэтому так и написали. Асинхронный значит от внешнего источника, а синхронны это сама программа. Например out of bouds, access violation, divide by zero, overflow -- это всё синхнонные события. Выполнил условие получил исключение.
Нет. Это именно асинхронные исключения — они возбуждаются внешним по отношению к приложению кодом. Точно так же, как и ctrl-c.

C>>Оно так и работает...

_>Что то я не помню чтобы ядро сисемы писали на С++. Видел только на C.
Посмотри на BeOS или L4 microkernel.

C>>"Абсолютно правильной(tm)" обработки исключений.

_>Вообще "Абсолютно правильной(tm)" уже торговая марка есть?
Угу. От "The One True Way Corporation".

C>>Ну да. А где же у нас float64 и double128?

_>а нафига тебе double128? я говорю об стандартных типах, которые можно встерить в файлах данных.
Ну почему же? Ты же хотел произвольные типы?

_>Имеется ввиду что иногда нужны типы данных не максимально быстро работающие на данном процессоре, а именно фиксированных параметров.

Это не имеет особого смысла в стандарте С++. Могу напомнить про PDP11 и прочие OS/390 с 36-битным int'ом.

C>>>>А для тех, кому не нравятся namespace'ы — рекомендую написать сложное приложение на JavaScript. Сколько бывает удовольствия...

_>>>javascript -- это не язык. это именно script и в нем слишком много ограничений, он для мелких поделок и DHTML.
C>>Кхм... Google Mail?
_>да и на бейсике можно программы писать. и что? дело в другом: одна и таже программа написаная на разных языках требует разный уровень затрат, и её будут иметь свои "профессиональные" проблеммы, которые определяются именно языком и тем способом которым программист опходит недостатки этого языка.
JavaScript — это как раз замечательный пример работы без namespace'ов. Так как оно кусается даже в небольших приложениях

C>>Я же просил — не говорить про урезаный эмулятор... Это очередные сложности на пустом месте.

_>Не понимаю, у вас все программы не используют float и double?
Да. Нафиг мне рассчёты на встроеной системе?

_>>>Просто у вас инертность большая и вы так привыкли. Но это безобразие.

C>>Нет, просто вы не писали реальных больших систем. Это сразу видно.
_>Да конешно, у вас есть фиксированный набор правил норм и шаблонов и вы их строго придерживаетесь как робот -- иначе труба. И это тоже сразу видно. Да в промышленном программировании свободы нет. Просто землекопы -- что дали тем и копаем. Просто тупо копаем, за остальное не платят. А свободного времени и не будет, так и умрём землекопами.
У меня в программировании один принцип — не добавлять сущности без необходимости.
Sapienti sat!
Re[12]: Cyberax
От: Left2 Украина  
Дата: 26.02.08 07:46
Оценка:
C>>>>>А для тех, кому не нравятся namespace'ы — рекомендую написать сложное приложение на JavaScript. Сколько бывает удовольствия...
_>>>>javascript -- это не язык. это именно script и в нем слишком много ограничений, он для мелких поделок и DHTML.
C>>>Кхм... Google Mail?
_>>да и на бейсике можно программы писать. и что? дело в другом: одна и таже программа написаная на разных языках требует разный уровень затрат, и её будут иметь свои "профессиональные" проблеммы, которые определяются именно языком и тем способом которым программист опходит недостатки этого языка.
C>JavaScript — это как раз замечательный пример работы без namespace'ов. Так как оно кусается даже в небольших приложениях

Зря вы JavaScript ругаете. Namespace-ы (вместе с модулями) на нём делаются малой кровью и в рамках уже существующего синтаксиса. Т.е. хочешь писать большое модульное приложение — пиши в определённом стиле. Не хочешь — ССЗБ. Но ведь и в языке с неймспейсами их использование носит характер рекомендации, а не требования.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[11]: Cyberax
От: dr.Chaos Россия Украшения HandMade
Дата: 26.02.08 11:27
Оценка:
kov_serg wrote:

> _>>Мдя. Ну нафига же мне эмулятор, всех команд сопроцессора. Арктангенс

> синус и логарифмы, если мне надо только перевод в целое, сложение и
> умножение? Ваши 73кб это от того что там много лишнего и ненужного,
> которое именно компилятор с линковщиком должны отбрасывать. C>Я же просил
> — не говорить про урезаный эмулятор... Это очередные сложности на пустом
> месте. Не понимаю, у вас все программы не используют float и double?

Я вот недавно напоролся (впервые за полтора года) на работу с float'ами.
Если б ты знал с каким удовольствием я бы заменил его на тип с
фиксированной точкой, но не могу, т.к. он в таком виде уже лет 10-15 в
проекте существует и шкурка выделки не стоит.

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

Короче, это я к тому, что пихать float везде очень неразумно.
Posted via RSDN NNTP Server 2.1 beta
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[12]: боязнь float и double
От: kov_serg Россия  
Дата: 26.02.08 13:31
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>Типы с плавающей точкой на пустом месте создают море тонких моментов

DC>(граблей), и если нет жёсткой необходимости их использовать, то лучше
DC>обойтись вычислениями с фиксированной точкой.
Я не понимаю, откуда такая фобия? Почему вы боитесь одних алгоритмов, при этом используете другие менее отлаженные и оптимизированные без зазрения совести.

DC>Короче, это я к тому, что пихать float везде очень неразумно.

Хочу вас успокоить с типами с фиксированной точкой проблем гораздо больше, и главная это переполнение.
А вторая -- этого типа нет в стандарте, и всегда приходится пользовать велосипед.
Почему нельзя тип fixed (16.16) добавить в стандарт на ряду с float и double? Интересно что мешает?
Re[14]: боязнь float и double
От: kov_serg Россия  
Дата: 26.02.08 16:01
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

>> Здравствуйте, dr.Chaos, Вы писали:

>>
>> DC>Типы с плавающей точкой на пустом месте создают море тонких моментов
>> DC>(граблей), и если нет жёсткой необходимости их использовать, то лучше
>> DC>обойтись вычислениями с фиксированной точкой.
>> Я не понимаю, откуда такая фобия? Почему вы боитесь одних алгоритмов, при
>> этом используете другие менее отлаженные и оптимизированные без зазрения
>> совести.
DC>:/ Мда-а-а. А откуда ты узнал какие алгоритмы я использую? Мелофон? Или со
DC>спутника узрел? При чём тут алгоритмы? Значения с плавающей точкой
DC>значительно более капризны при вычислениях, хотя бы потому, что вычисления
DC>с ними не точные, за счёт представления. Я не вижу смысла использовать их
DC>бездумно.
Очень просто если не используете float и double, для вычислений то вы используете что то другое :P
И миелофон не понадобился. И потом вам нужна процессорная мощь и распределенные вычисления, но не нежны типы данных с плавающей точкой?
Очень, очень странно. Для чего же вы используете вычислительную технику? Для вывода спец эффектов в висте?

>> DC>Короче, это я к тому, что пихать float везде очень неразумно.

>> Хочу вас успокоить с типами с фиксированной точкой проблем гораздо больше, и главная это переполнение.
DC>Да ну? А с чем ещё?
Много еще overflow, underflow, математические функции и т.п. но в ряде узкоспециализированных задачах он просто незаменимый.
И встроенная эффективная поддержка в компилятор была бы очень полезна. Тем более что это не сложно.

>> А вторая -- этого типа нет в стандарте, и всегда приходится пользовать

DC>велосипед. Почему нельзя тип fixed (16.16) добавить в стандарт на ряду с
DC>float и double? Интересно что мешает?
DC>Да и float с double поддерживаются на довольно низком уровне. А
DC>универсального решения всё равно не напишешь, т.к. области могут быть очень
DC>разными.
А кто говорит об общем решении. Но эти типы очень широко и успешно применяются. А fixed тоже очень простой тип его очень легко поддерживать.
Специально как промежуточного звена между int и float для тех кому религия запрещает пользоваться типами float и double.
Так почему такого типа в стандарте нет? зато std::size_t есть. Я негодую!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.