Здравствуйте, MasterZiv, Вы писали:
MZ>jazzer пишет: >> The whole committee expressed a strong desire to deliver the next C++ >> Standard in 2009.
MZ>Зачем догружать и без того уже офигенно сложный язык ? MZ>Может уже пора делать из него новый ?
Вот здесь Страуструп очень интересно пишет на этот счёт. Дядька хоть уже и старый, но всё ещё умный
Вот пара цитат прямо по теме:
There are more useful systems developed in languages deemed awful than in languages praised for being beautiful – many more. The purpose of a programming language is to help build good systems, where “good” can be defined in many ways. My brief definition is “correct, maintainable, and adequately fast”. Aesthetics matter, but first and foremost a language must be useful; it must allow real-world programmers to express real-world ideas succinctly and affordably. People tend to forget this and argue over programming
style or language features using small contrived examples. A programming language is a small – but often highly visible – piece in a huge puzzle.
The main reason for C++’s success is simply that it meets its limited design aims: it can express a huge range of ideas directly and efficiently. C++ was not designed to do just one thing really well or to prevent people doing things considered “bad.” Instead, I concentrated on generality and performance. In C++, you can write code that is simultaneously elegant and efficient. Naturally, you can also write code that is neither, and many people couldn’t recognize elegance if it walked up and punched them in the nose – but that’s true for every language. C++’s strengths lies in the huge range of what it is pretty good at rather than in what it’s superb at.
...
C++ is designed to allow you to express ideas, but if you don’t have ideas or don’t have any clue about how to express them, C++ doesn’t offer much help. In that, C++ is not that different from other languages, but it is different from languages/systems/tools/frameworks designed to make it easy to express specific things in a specific domain.
...
C++ has indeed become too expert friendly at a time where the degree of effective formal education of the average software developer has declined. However, the solution is not to dumb down the programming languages but to use a variety of programming languages and educate more experts. There has to be languages for those experts to use – and C++ is one of those languages.
Вот, что из он заключает из этого:
We need relatively complex language to deal with absolutely complex problems.
Я с ним согласен. То, что появится какой-то _простой_ язык, на котором можно будет научиться профессионально программировать на двух недельных курсах, и после этого создавать какие-то реальные приложения — это полная утопия и миф, который поддерживают компании, которые хотят впаривать якобы такие языки, и их поддерживают тупые менеждеры, которые верят, что они смогут понанимать дешёвых, неопытных программистов и таким образом достигнут высокой эффективности вложений.
Никого же не удивляет, что очень сложно строить мосты и небоскрёбы, и что этим занимаются только опытные профессионалы. Никого не удивляет, что лекарства создают только профессионалы. Никого не удивляет, что пособие по анатомии для докторов на порядок сложнее и детализированнее любой книги по программированию. Кто готов жить в доме/летать на самолёте/принимать лекарства/..., которые сделал некто, кто прошёл некие двух-недельные курсы по некой новомодной очень-простой-для-дебилов методике.
Вобщем _реальный_ язык программирования всегда будет сложным и создавать системы на нём смогут только профессионалы и тут ничего не поделать.
К сожалению в области создания ПО сейчас сложилась очень нездоровая ситуация, когда многие (причём и люди очень высокого звена) считают, что не надо использовать _сложные_ языки и не надо нанимать опытных профессионалов, всё тоже для них смогут сделать студенты на новом разрекламированном языке.
Напоследок ещё одна цитата — просто очень понравиась:
why do I see character echo delays in Word on my 2GHz, 2Gb computer? I didn’t see that on my editor on a shared 1MHz, 1Mb PDP11 25 years ago
R>We need relatively complex language to deal with absolutely complex problems.
Во только С++ черизвычайно сложный и позволяет решать относительно сложные задачи...
А для абсолютно сложных задач нужно что-то попроще и помощьнее.
R>Вобщем _реальный_ язык программирования всегда будет сложным и создавать системы на нём смогут только профессионалы и тут ничего не поделать. R>К сожалению в области создания ПО сейчас сложилась очень нездоровая ситуация, когда многие (причём и люди очень высокого звена) считают, что не надо использовать _сложные_ языки и не надо нанимать опытных профессионалов, всё тоже для них смогут сделать студенты на новом разрекламированном языке.
Твое заявление из тойже серии что говорить: Зачем нужны все эти сверхпрочные материалы? Для того чтобы любой дворник мог построить мост через ручей? Так профессионал может построить его из обычнах досок!
Нет! Они нужны для того чтобы профессионалы могли строить многокилометровые мосты через проливы в сейсмоопасных районах.
Простые языки вернее языки которыми просто пользоваться нужны не для того чтобы могли писать домохозяйки. Они никогда не смогут писать и ни один разумный человек с этим спорить не станет.
Они нужны для того чтобы повысить производительность профессиональных программистов. Они нужны для того чтобы профессионал мог решать задачу, а не обходить грабли языка. Они нужны чтобы можно было создовать то что раньше сделать было нереально (слишком сложно в том числе из-за граблей в языке).
Не нужно оправдывать сложность языка сложностью задач. Для сложных задач нужен мощьный, а не сложный язык. А если для сложной задачи взять сложный язык то сложность работы возрастет многократно ибо придется бороться не только со сложностью задачи но и со сложностью языка.
R>Напоследок ещё одна цитата — просто очень понравиась: R>
R>why do I see character echo delays in Word on my 2GHz, 2Gb computer? I didn’t see that on my editor on a shared 1MHz, 1Mb PDP11 25 years ago
Угу вот только word написан на С/С++.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
ну как же тут без вас? Без вас уже ничего теперь не обходится.
R>>Напоследок ещё одна цитата — просто очень понравиась: R>>
R>>why do I see character echo delays in Word on my 2GHz, 2Gb computer? I didn’t see that on my editor on a shared 1MHz, 1Mb PDP11 25 years ago
WH>Угу вот только word написан на С/С++.
а тот, на который он не жаловался 25 лет назад видимо был написан на c#?
При всем уважении к c# он не является тем самым "мощным" языком.
Чем больше пишу на с++, тем больше понимаю, что в нем ооочень много дыр и он ооочень сложен. Чем больше пишу на C#, тем больше понимаю, что что-то в нем не так
Здравствуйте, Константин Л., Вы писали:
КЛ>а тот, на который он не жаловался 25 лет назад видимо был написан на c#? КЛ>При всем уважении к c# он не является тем самым "мощным" языком.
А где я сказал C#? Может будешь читать то что написано, а не то что тебе хочется читать?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
R>>
R>>We need relatively complex language to deal with absolutely complex problems.
WH>Во только С++ черизвычайно сложный и позволяет решать относительно сложные задачи...
Какие интересно задачи не позволяет решать С++? Имхо, если С++ сегодня не позволяет, то ни один язык сегодня не позволяет её решить.
WH>А для абсолютно сложных задач нужно что-то попроще и помощьнее.
Под complex он подразумевает не сложный (как алгоритм), а скорее комплексный. Т.е. некая real-world задача с неким абсолютно непредсказуемым набором нефункциональных требований, и которые могут непредсказыемым образом эволюционировать.
В одной из других статей (сейчас точно не помню в какой) он так же писал про понятие т.н. семантической пропасти языка. Это когда вдруг появляется некое требование, которое изначально не было учтено, и которое язык принципиально не позволяет реализовать.
Часто такими требованиями бывает портируемость не некую платформу, производительность, потребление памяти, доступ к аппаратному обеспечению, полный доступ к возможностям ос и т.д.
Как бы это не было печально (или кому наоборот хорошо) и сегодня из-за семантической пропасти некое множество систем, написанных на языках _попроще_, или терпит крах или переписывается на С/С++...
WH>Простые языки вернее языки которыми просто пользоваться нужны не для того чтобы могли писать домохозяйки. Они никогда не смогут писать и ни один разумный человек с этим спорить не станет. WH>Они нужны для того чтобы повысить производительность профессиональных программистов. Они нужны для того чтобы профессионал мог решать задачу, а не обходить грабли языка. Они нужны чтобы можно было создовать то что раньше сделать было нереально (слишком сложно в том числе из-за граблей в языке).
WH>Не нужно оправдывать сложность языка сложностью задач. Для сложных задач нужен мощьный, а не сложный язык. А если для сложной задачи взять сложный язык то сложность работы возрастет многократно ибо придется бороться не только со сложностью задачи но и со сложностью языка.
Во-первых, язык с++ не такой уж и сложный для пофессионалов (ты согласился, что домохозяйкам не надо давать программировать).
Во-вторых, не так уж там много граблей.
В-третьих, язык С++ очень мощный по выразительной мощности и по возможности абстрагироваться, и пакетировать функциональность (создавать повторноиспользуемые компоненты). По крайней мере из императивных языков.
Вобщем, Страуструп там действительно очень грамотно пишет, и на все эти вопросы отвечает (лучше меня). Рекомендую прочитать.
R>>Напоследок ещё одна цитата — просто очень понравиась: R>>
R>>why do I see character echo delays in Word on my 2GHz, 2Gb computer? I didn’t see that on my editor on a shared 1MHz, 1Mb PDP11 25 years ago
WH>Угу вот только word написан на С/С++.
Это он о другом там говорит — об сегодняшнем образовании и об сегодняшнем подходе. И вообще:
In C++, you can write code that is simultaneously elegant and efficient. Naturally, you can also write code that is neither...
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Константин Л., Вы писали:
КЛ>>а тот, на который он не жаловался 25 лет назад видимо был написан на c#? КЛ>>При всем уважении к c# он не является тем самым "мощным" языком. WH>А где я сказал C#? Может будешь читать то что написано, а не то что тебе хочется читать?
Здравствуйте, remark, Вы писали:
WH>>Во только С++ черизвычайно сложный и позволяет решать относительно сложные задачи... R>Какие интересно задачи не позволяет решать С++? Имхо, если С++ сегодня не позволяет, то ни один язык сегодня не позволяет её решить.
Например компилятор nemerle. Написать его на С++ настолько сложная задача что справится с ней не сможет даже мелкософт с его гигабаксами. Меж тем на nemerle его ниписали два студента.
И больше всего у них проблем возникает с ошибками в CLR который сам понимаешь кем и начем написан. А ведь мелкософт может позволить себе нанять элиту.
Что уж говорить о конторах помельче...
WH>>А для абсолютно сложных задач нужно что-то попроще и помощьнее. R>Под complex он подразумевает не сложный (как алгоритм), а скорее комплексный. Т.е. некая real-world задача с неким абсолютно непредсказуемым набором нефункциональных требований, и которые могут непредсказыемым образом эволюционировать.
И как тут поможет С++?
R>Как бы это не было печально (или кому наоборот хорошо) и сегодня из-за семантической пропасти некое множество систем, написанных на языках _попроще_, или терпит крах или переписывается на С/С++...
Примеры в студию.
R>Во-первых, язык с++ не такой уж и сложный для пофессионалов (ты согласился, что домохозяйкам не надо давать программировать).
Я сейчас работаю в одной очень крупной и богатой конторе. Основная разработка идет на С++.
Персонал набирают очень придирчиво.
Так вот даже тут есть всего человек 10 (не больше) у которых с С++ почти нет проблем. R>Во-вторых, не так уж там много граблей.
Это ты мне не расказывай ладно? R>В-третьих, язык С++ очень мощный по выразительной мощности и по возможности абстрагироваться, и пакетировать функциональность (создавать повторноиспользуемые компоненты). По крайней мере из императивных языков.
Раскажи это тем кто не пишет сложные кроссплатформенные системы на С++ ладно?
Что касается выразительности то покажи мне сериализацию на С++, а потом я тебе покажу сериализацию на nemerle.
Да вобще просто посмотри http://nemerle.org/svn/nemerle/trunk/macros/ и подумай как это все будет выглядеть на С++.
И это при том что nemerle не идеал и можно сделать лучше.
R>Это он о другом там говорит — об сегодняшнем образовании и об сегодняшнем подходе. И вообще: R>
R>In C++, you can write code that is simultaneously elegant and efficient. Naturally, you can also write code that is neither...
Это относится почти ко всем языкам.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, remark, Вы писали:
R>В-третьих, язык С++ очень мощный по выразительной мощности и по возможности абстрагироваться, и пакетировать функциональность (создавать повторноиспользуемые компоненты). По крайней мере из императивных языков.
Кстати насчет выразительности С++: Чем заменить if () else if() else if() else if() else...
хм...Издеваешься? Нормальный человек бы описание хоть привел, что тут должно делаться. И то, что ты его не привел — твоя проблема. И не удивляйся, что нико не захочет тебе на это отвечать.
Здравствуйте, Константин Л., Вы писали:
КЛ>разве ты не из тех любителей почморить с++ при каждом удобном случае?
Нет.
В данном случае я увидел ложное утверждение что для сложных задач нужен сложный язык. И высказался именно по поводу этого утверждения. С++ тут попался лишь как пример черезмерно усложненного языка при этом не обладающий большой выразительностью.
КЛ>Мы к вам в .NET векту не лезем и не говорим, что там на чем было написано.
Кому это к нам? У меня нет барикадного синдрома в отличии от...
Чтоб ты знал: прямо сейчас я пишу кластерный софт на С++ под линукс.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Константин Л., Вы писали:
КЛ>>разве ты не из тех любителей почморить с++ при каждом удобном случае? WH>Нет. WH>В данном случае я увидел ложное утверждение что для сложных задач нужен сложный язык. И высказался именно по поводу этого утверждения. С++ тут попался лишь как пример черезмерно усложненного языка при этом не обладающий большой выразительностью.
ну в другой ветке этого же топика ты все-таки перешел на личности (это я про Nemerle). Зачем это тут?
btw, c# я бы тоже не назвал простым языком. пусть даже он проще с++. и с выразительностью у него тоже не лучше, особенно c# 1.0
Здравствуйте, Константин Л., Вы писали:
КЛ>ну в другой ветке этого же топика ты все-таки перешел на личности (это я про Nemerle).
Пример языка попроще и помощьнее. Вренее сильно проще и сильно мощьнее.
Но и немерле не идеал. Можно еще проще и мощьнее.
Лиспоманам: Нет это не лисп. КЛ>Зачем это тут?
За тем что я пытаюсь обсудить тезис о том что для сложных задач нужны сложные языки, а ты зачемто все пытаешься свести к тупому холивару
КЛ>btw, c# я бы тоже не назвал простым языком. пусть даже он проще с++. и с выразительностью у него тоже не лучше, особенно c# 1.0
Еще раз спрашиваю: Где я говорил про C#?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
[]
WH>За тем что я пытаюсь обсудить тезис о том что для сложных задач нужны сложные языки, а ты зачемто все пытаешься свести к тупому холивару
ок. Однако корреляция м/у сложность ю мощность все же существует. Имхо.
Мне холивар не нужен. Но больше всего мне тут не нужно обсуждение с++ как языка с кучей костылей. Все мы это уже слышали.
и все-таки он должен быть сложным. Может быть не таким как с++, но все же.
КЛ>>btw, c# я бы тоже не назвал простым языком. пусть даже он проще с++. и с выразительностью у него тоже не лучше, особенно c# 1.0 WH>Еще раз спрашиваю: Где я говорил про C#?
Здравствуйте, Константин Л., Вы писали:
КЛ>ок. Однако корреляция м/у сложность ю мощность все же существует. Имхо.
Очень слабая. КЛ>Мне холивар не нужен. Но больше всего мне тут не нужно обсуждение с++ как языка с кучей костылей. Все мы это уже слышали.
А зачем тогда ты сводишь разговор к этому? КЛ>и все-таки он должен быть сложным. Может быть не таким как с++, но все же.
Не должен.
КЛ>c#, nemerle, какая разница Это пять! Дальше можно не продолжать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH> Это пять! Дальше можно не продолжать.
Вот именно! И не только можно, но и нужно!!!
Ну правда, оставь тему для обсуждения фич C++, а не того, что его надо вообще нафиг порушить.
Я не спорю, что надо, но фичи как-то конструктиынее
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Константин Л., Вы писали:
КЛ>>ок. Однако корреляция м/у сложность ю мощность все же существует. Имхо. WH>Очень слабая. КЛ>>Мне холивар не нужен. Но больше всего мне тут не нужно обсуждение с++ как языка с кучей костылей. Все мы это уже слышали. WH>А зачем тогда ты сводишь разговор к этому?
я свожу? Где?
КЛ>>и все-таки он должен быть сложным. Может быть не таким как с++, но все же. WH>Не должен.
КЛ>>c#, nemerle, какая разница WH> Это пять! Дальше можно не продолжать.
Здравствуйте, WolfHound, Вы писали:
WH>А как на С++ написать что-то типа такого...
От туда же:
Q: How importance is elegance in a computer language?
Elegance is essential, but how do you measure “elegance”? The lowest number of characters to express the solution to the “towers of Hanoi” problem? My view is that we should look for elegance in the applications built, the code written, rather than in the languages themselves. It would be a stretch to call a carpenter’s complicated set of tools – many quite dangerous – elegant. The true worth of a craftsman’s tools is only appreciated by craftsmen.
Здравствуйте, WolfHound, Вы писали:
WH>А как на С++ написать что-то типа такого ...
Хорошо, теперь я поглядел код
Опять цитатой от туда же (уж больно мне понравилось )
C++’s strengths lies in the huge range of what it is pretty good at rather than in what it’s superb at.
Да, тут nemerle рулит. В С++ есть паттерн-матчинг, но конечно не такой сильный...
Ну а как насчёт, ну не знаю, доступа к регистрам аппаратуры, или "написания программы на машинном коде" (ну это когда ты пишешь программу на яву, но при этом фактически знаешь, что будет делать процессор). Может это конечно тоже есть в nemerle — не знаю. В С++ есть и фичи для программирования на очень высоком уровне абстракции. Может оно, конечно, тоже не такое хорошее как в nemerle, но суть в том, что оно есть _всё_. На с++ я могу сделать всё. Пусть для чего-то мне понадобится в начале сделать свою библиотеку, и синтаксис будет не такой красивый. Но преград нет. В этом суть.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
WH>>>Во только С++ черизвычайно сложный и позволяет решать относительно сложные задачи... R>>Какие интересно задачи не позволяет решать С++? Имхо, если С++ сегодня не позволяет, то ни один язык сегодня не позволяет её решить. WH>Например компилятор nemerle. Написать его на С++ настолько сложная задача что справится с ней не сможет даже мелкософт с его гигабаксами. Меж тем на nemerle его ниписали два студента. WH>И больше всего у них проблем возникает с ошибками в CLR который сам понимаешь кем и начем написан. А ведь мелкософт может позволить себе нанять элиту. WH>Что уж говорить о конторах помельче...
no programming language is or could be a panacea, not even C++
WH>>>А для абсолютно сложных задач нужно что-то попроще и помощьнее. R>>Под complex он подразумевает не сложный (как алгоритм), а скорее комплексный. Т.е. некая real-world задача с неким абсолютно непредсказуемым набором нефункциональных требований, и которые могут непредсказыемым образом эволюционировать. WH>И как тут поможет С++?
У него нет семантической пропасти.
R>>Как бы это не было печально (или кому наоборот хорошо) и сегодня из-за семантической пропасти некое множество систем, написанных на языках _попроще_, или терпит крах или переписывается на С/С++... WH>Примеры в студию.
Был свидетелем как переписывали с явы — не тянула требования работать на очень слабых машиных, которое вначале как-то не учли, а потом уже не смогли ничего сделать...
С явы и шарпа, слышал, переписывают, когда по портируемости не тянет.
R>>Во-первых, язык с++ не такой уж и сложный для пофессионалов (ты согласился, что домохозяйкам не надо давать программировать). WH>Я сейчас работаю в одной очень крупной и богатой конторе. Основная разработка идет на С++. WH>Персонал набирают очень придирчиво. WH>Так вот даже тут есть всего человек 10 (не больше) у которых с С++ почти нет проблем.
А говорил, что вообще будет легко?
R>>Во-вторых, не так уж там много граблей. WH>Это ты мне не расказывай ладно?
Ну не знаю, я сейчас работаю, особых проблем не встречается. Но встречаются конечно, но не то, что б очень всё плохо.
R>>В-третьих, язык С++ очень мощный по выразительной мощности и по возможности абстрагироваться, и пакетировать функциональность (создавать повторноиспользуемые компоненты). По крайней мере из императивных языков. WH>Раскажи это тем кто не пишет сложные кроссплатформенные системы на С++ ладно? WH>Что касается выразительности то покажи мне сериализацию на С++, а потом я тебе покажу сериализацию на nemerle. WH>Да вобще просто посмотри http://nemerle.org/svn/nemerle/trunk/macros/ и подумай как это все будет выглядеть на С++.
А это не важно. Важно то, что real-world приложения сейчас пишут на С++. На чём, ты там говорил, ты пишеть кластерный сервер? Почему не на немерле?
Здравствуйте, WolfHound, Вы писали:
R>>В-третьих, язык С++ очень мощный по выразительной мощности и по возможности абстрагироваться, и пакетировать функциональность (создавать повторноиспользуемые компоненты). По крайней мере из императивных языков. WH>Раскажи это тем кто не пишет сложные кроссплатформенные системы на С++ ладно?
А какие у них проблемы?
WH>Что касается выразительности то покажи мне сериализацию на С++, а потом я тебе покажу сериализацию на nemerle. WH>Да вобще просто посмотри http://nemerle.org/svn/nemerle/trunk/macros/ и подумай как это все будет выглядеть на С++.
Поглядел:
Copyright (c) 2003, 2004 The University of Wroclaw.
Всё ясно
Диплом/кандидатскую кто-то видимо защитил
А если серьёзно, то — да как хочешь она будет выглядеть.
Есть просто надо ограниченный набор структур сериализовать — то просто перечислением полей в функции сериализации.
Если сериализовать действительно много — то можно подумать о генераторе кода — perl/самописный/готовый — asn.1 или ещё что-то.
Можно препроцессор подпрячь.
Можно описать список полей на template metaprogramming, тогда получится compile-time рефлекшн.
Можно ввести базовые классы для классов и полей, что б автоматически собирать информацию о структуре.
...
В общем несколько хватит фантации и какие требования.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
WH>>>Во только С++ черизвычайно сложный и позволяет решать относительно сложные задачи... R>>Какие интересно задачи не позволяет решать С++? Имхо, если С++ сегодня не позволяет, то ни один язык сегодня не позволяет её решить. WH>Например компилятор nemerle. Написать его на С++ настолько сложная задача что справится с ней не сможет даже мелкософт с его гигабаксами. Меж тем на nemerle его ниписали два студента. WH>И больше всего у них проблем возникает с ошибками в CLR который сам понимаешь кем и начем написан. А ведь мелкософт может позволить себе нанять элиту. WH>Что уж говорить о конторах помельче...
ну .net с++ осилил же. Или он тоже не на с++ написан?
и много там в CLR ошибок? Что-то сомневаюсь, что они только и знают, что продираться среди них.
PS: Ну вот по-хорошему проигнорировать тебя надо. А то на тухлую дорожку идем. Больше по этой теме не высказываюсь.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
R>>
R>>We need relatively complex language to deal with absolutely complex problems.
WH>Во только С++ черизвычайно сложный и позволяет решать относительно сложные задачи... WH>А для абсолютно сложных задач нужно что-то попроще и помощьнее.
Парни, имхо, вопрос философский и должен идти в соответствующий форум
Давай отделим ветку...
Здравствуйте, remark, Вы писали:
R>Здравствуйте, WolfHound, Вы писали:
WH>>Здравствуйте, remark, Вы писали:
R>>>
R>>>We need relatively complex language to deal with absolutely complex problems.
WH>>Во только С++ черизвычайно сложный и позволяет решать относительно сложные задачи...
R>Какие интересно задачи не позволяет решать С++? Имхо, если С++ сегодня не позволяет, то ни один язык сегодня не позволяет её решить.
В C++ даже нет такого базового свойства как рефлексия. Дальше можно не продолжать.
WH>>А для абсолютно сложных задач нужно что-то попроще и помощьнее.
R>Под complex он подразумевает не сложный (как алгоритм), а скорее комплексный. Т.е. некая real-world задача с неким абсолютно непредсказуемым набором нефункциональных требований, и которые могут непредсказыемым образом эволюционировать.
R>В одной из других статей (сейчас точно не помню в какой) он так же писал про понятие т.н. семантической пропасти языка. Это когда вдруг появляется некое требование, которое изначально не было учтено, и которое язык принципиально не позволяет реализовать.
R>Часто такими требованиями бывает портируемость не некую платформу, производительность, потребление памяти, доступ к аппаратному обеспечению, полный доступ к возможностям ос и т.д.
Это как раз к семантике (т.е. смыслу программы) никакого отношения не имеет. Это чисто технические подробности реализации.
R>Как бы это не было печально (или кому наоборот хорошо) и сегодня из-за семантической пропасти некое множество систем, написанных на языках _попроще_, или терпит крах или переписывается на С/С++...
Примеры?
R>Во-первых, язык с++ не такой уж и сложный для пофессионалов (ты согласился, что домохозяйкам не надо давать программировать).
) которые дают просто таки комбинаторный взрыв разных очень заковыристых случаев. А если еще вспомнить про всякие SFINAE .
R>Во-вторых, не так уж там много граблей.
R>В-третьих, язык С++ очень мощный по выразительной мощности и по возможности абстрагироваться, и пакетировать функциональность (создавать повторноиспользуемые компоненты). По крайней мере из императивных языков.
Он очень слаб с точки зрения создания повторноиспользуемых компонент, поскольку
1) нет стандарта ABI. Попробуй-ка хотя бы передать std::vector из программы скомпилированной компилятором A в библиотеку скомпилированную компилятором B и там его заресайзить. Это 100% UB.
2) нет нормальной системы модулей как в .NET/JVM/whatever, есть заголовочные файлы, которые просто текст, который вообще-то говоря никто не запрещает менять и после компиляции библиотеки при этом возможны любые ошибки. Как насчет изменения pragma pack? Я уж не говорю что чтобы это более менее быстро компилировалось нужны всякие свистопляски с guards и precompiled headers, что вообще костыли .
R>Вобщем, Страуструп там действительно очень грамотно пишет, и на все эти вопросы отвечает (лучше меня). Рекомендую прочитать.
Он выступает в основном против упрощения программирования и считает, что профессионалам нужны мощные инструменты. С этим я согласен.
R>>>Напоследок ещё одна цитата — просто очень понравиась: R>>>
R>>>why do I see character echo delays in Word on my 2GHz, 2Gb computer? I didn’t see that on my editor on a shared 1MHz, 1Mb PDP11 25 years ago
WH>>Угу вот только word написан на С/С++.
R>Это он о другом там говорит — об сегодняшнем образовании и об сегодняшнем подходе. И вообще:
R>[q] R>In C++, you can write code that is simultaneously elegant and efficient.
У меня elegant не получается . Хотя бы потому что нет foreach и вывода типов. Да и с efficient не всегда получается (т.к. стандартные malloc/new довольно медленные по сравнению с выделением памяти в .NET/Java).
D уже лучше в этом смысле, хотя там от многих вещей которые мне нравятся в C++ (const, ссылки, перегрузка=) отказались.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, WolfHound, Вы писали:
WH>>Здравствуйте, remark, Вы писали:
R>>>
R>>>We need relatively complex language to deal with absolutely complex problems.
WH>>Во только С++ черизвычайно сложный и позволяет решать относительно сложные задачи... WH>>А для абсолютно сложных задач нужно что-то попроще и помощьнее.
J>Парни, имхо, вопрос философский и должен идти в соответствующий форум J>Давай отделим ветку...
Мои два цента в дискуссию — из того же Страуструпа:
However, the solution is not to dumb down the programming languages but to use a variety of programming languages and educate more experts. There has to be languages for those experts to use – and C++ is one of those languages.
Нужно пользоватся всем, что предоставил нам человеческий гений в лице творцов языков и прочего.
А то получается (пользуясь аналогией Бьярне), что два плотника спорят, что лучше — гвозди или шурупы.
Причем споря не для конкретных случаев, а вообще.
То, что у С++ много проблем — никто с этим не спорит, иначе бы комитет не занимался ничем и понятия C++ evolution не было бы вообще.
Направления развития понятны и четко озвучены (это видно на обсуждаемой страничке комитета), и никто не пребывает в эйфории, думая, что С++ идеален.
К сожалению, то, что язык никому не принадлежит, а используется всеми, делает процесс стандартизации слишком сложным и долгим, в отличие от проприетарных языков типа жавы и шарпа.
Здравствуйте, jazzer, Вы писали:
J>К сожалению, то, что язык никому не принадлежит, а используется всеми, делает процесс стандартизации слишком сложным и долгим, в отличие от проприетарных языков типа жавы и шарпа.
Это спорный вопрос. Проприетарные языки развиваются узкой группой людей, которых никто не знает, которые мотивированы непонятно чем. В результате язык становится заложником корпоративной политики. Вспомни яву. Язык не развивался много лет пока не появился .Net.
C++ же развивался под воздействием требований разработчиков, возникших не на пустом месте, и не вымученых из головы, а основаных на опыте практического применения. Результат налицо.
Здравствуйте, WolfHound, Вы писали:
R>>В-третьих, язык С++ очень мощный по выразительной мощности и по возможности абстрагироваться, и пакетировать функциональность (создавать повторноиспользуемые компоненты). По крайней мере из императивных языков. WH>Раскажи это тем кто не пишет сложные кроссплатформенные системы на С++ ладно?
Вот тут не очень понял. Ты имеешь ввиду, что сложные кроссплатформенные системы нельзя писать на C++? Или что тем, кто не пишет сложных кроссплатформенных систем, C++ с его фичами не нужен?
WH>Что касается выразительности то покажи мне сериализацию на С++, а потом я тебе покажу сериализацию на nemerle.
-- хотелось бы посмотреть на аналогичные средства в Nemerle (как говорится здесь и сейчас, по факту ). Чтобы там было расширение типов в будущем, в том числе и для наследования.
А еще можно попросить показать реализацию ASN.1 на Nemerle, тоже интересно посмотреть, когда она вообще появится.
Я это к тому, что для C++ при всех его проблемах есть достаточное количество наработок, которые для других, "более правильных" языков еще нужно делать, делать и делать. А программы нужно писать здесь и сейчас.
Если же говорить по теме ветки, то, имхо, сейчас очень большая проблема с C++ в том, что ему нужно учить людей годы. В то время как конкуренты (могу смело говорить за Java) осваиваются гораздо быстрее (по крайней мере на том уровне, когда на ровном месте люди на грабли не наступают). А в C++ сейчас проекты развиваются не по пути упрощения, а наоборот -- усложнения. Например, Boost во многих местах имеет сложную реализацию. И это считается нормальным, мол, это библиотечный код, пользователям в него заглядывать не нужно. А мне кажется, что наоборот -- язык должен быть таким, чтобы даже сложные вещи в нем можно было реализовывать так, чтобы не сильно продвинутые программисты могли в реализации разобраться. И, мне кажется, на C++ можно именно так и программировать (пример -- ACE). Но вот что-то C++ привлекает к себе любителей понапридумывать сложностей... Поэтому с точки зрения обучения C++у молодежи C++ вообще в очень тяжелом положении.
А нововедения в стандарт, мне кажется, еще больше повысят порог вхождения.
Из-за чего может получится эффект выжженой земли -- заматеревшие C++ программисты, которые уже давно на нем работаю и никуда не переходят, получат от C++09 выгоды. Но молодежь к C++у будет обращаться все реже и реже, соответственно, образуется пробел между поколениями "старых" и "молодых" программистов.
Такое вот MHO.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
[]
АХ>В C++ даже нет такого базового свойства как рефлексия. Дальше можно не продолжать.
Хе-хе. Она мне в с# почти ни разу не пригодилась, не говоря уже о с++. Имхо рефлексия нужна там, где есть ошибки проектирования (сериализацию и т.п. в расчет не берем).
) которые дают просто таки комбинаторный взрыв разных очень заковыристых случаев. А если еще вспомнить про всякие SFINAE .
И че там такого сложного? Хочешь испугать — приводи че-нить посложнее.
R>>Во-вторых, не так уж там много граблей.
АХ>
кто про что, а вшивый про баню
R>>В-третьих, язык С++ очень мощный по выразительной мощности и по возможности абстрагироваться, и пакетировать функциональность (создавать повторноиспользуемые компоненты). По крайней мере из императивных языков.
АХ>Он очень слаб с точки зрения создания повторноиспользуемых компонент, поскольку
В общем согласен. Но COM продвинул с++ в этом плане.
WH>Например компилятор nemerle. Написать его на С++ настолько сложная задача что справится с ней не сможет даже мелкософт с его гигабаксами. Меж тем на nemerle его ниписали два студента.
Ну-ну, вон три человека сумели компилятор С++ с экспортом шаблонов написать, да еще и на С. Наверное, справились бы и с немерле.
Of course, the code must be complete enough to compile and link.
Здравствуйте, Константин Л., Вы писали:
АХ>>В C++ даже нет такого базового свойства как рефлексия. Дальше можно не продолжать.
КЛ>Хе-хе. Она мне в с# почти ни разу не пригодилась, не говоря уже о с++. Имхо рефлексия нужна там, где есть ошибки проектирования КЛ> (сериализацию и т.п. в расчет не берем).
Почему не берем? Это одна из базовых и необходимейших задач, а ее значение в свете веб-сервисов еще важнее. А также сюда же AOP, Unit Tests и еще много других нужных и полезных технологий.
АХ>>Да? Да все тонкости C++ мало кто знает. В нем слишком много концепций (см. хотя бы Re[4]: Посоветуйте книжку по С++.
) которые дают просто таки комбинаторный взрыв разных очень заковыристых случаев. А если еще вспомнить про всякие SFINAE .
КЛ>И че там такого сложного? Хочешь испугать — приводи че-нить посложнее.
Да каждая вещь кажется сама по себе несложной, но когда их вместе применяют возможны самые неожиданные эффекты, при этом компилятор еще и пытается как правило в случае неоднозначности "угадать" лучший вариант .
АХ>>Он очень слаб с точки зрения создания повторноиспользуемых компонент, поскольку
КЛ>В общем согласен. Но COM продвинул с++ в этом плане.
COM — это кроссязыковая технология и при этом такой жутик, что MS пришлось сделать .NET. При этом собственно изначально .NET возник из проекта по добавлению метаданных к C++ (здесь), но в процессе оказалось что для полноценной компонентной технологии этого мало.
Здравствуйте, Шахтер, Вы писали:
Ш>Это спорный вопрос. Проприетарные языки развиваются узкой группой людей, которых никто не знает,
Ну как правило этих людей все знают .
Ш> которые мотивированы непонятно чем.
Они мотивированы конкуренцией. Т.е. язык который они сделают должен быть чем-то лучше чем те которые уже есть, тогда он сможет отвоевать у них часть рынка. Поэтому его необходимо сделать лучше чем существующие.
Ш> В результате язык становится заложником корпоративной политики.
Только отчасти. Если корпорация будет пытаться слишком подминать под себя разработчиков они уйдут к конкурирующим языкам.
Ш>Вспомни яву. Язык не развивался много лет пока не появился .Net.
+1. Вот оно — благотворное влияние конкуренции.
Ш>C++ же развивался под воздействием требований разработчиков, возникших не на пустом месте, и не вымученых из головы, а основаных на опыте практического применения. Результат налицо.
В результате сборная солянка. Очень много чего напихали (и еще больше хотят) и теперь попробуй-ка напиши для этого дела компилятор. Я уж не говорю, что он жутко медленным будет.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, Шахтер, Вы писали:
Ш>>Это спорный вопрос. Проприетарные языки развиваются узкой группой людей, которых никто не знает,
АХ>Ну как правило этих людей все знают .
Вряд ли. Скажем C#. Библиотеки для него написаны толпой безликих программистов.
Известны обычно только несколько лидеров проекта.
Ш>> которые мотивированы непонятно чем.
АХ>Они мотивированы конкуренцией. Т.е. язык который они сделают должен быть чем-то лучше чем те которые уже есть, тогда он сможет отвоевать у них часть рынка. Поэтому его необходимо сделать лучше чем существующие.
Нет языковой конкуренции. java, скажем принадлежит просто другому классу чем C++, поэтому бессмысленно говорить о конкуренции java и C++.
Язык возникает как ответ на потребность в результате осмысления опыта. Этот процесс не может быть мотивирован конкуренцией.
Ш>> В результате язык становится заложником корпоративной политики.
АХ>Только отчасти. Если корпорация будет пытаться слишком подминать под себя разработчиков они уйдут к конкурирующим языкам.
Ага, щаз. Потрут весь code-base и уйдут.
Ш>>Вспомни яву. Язык не развивался много лет пока не появился .Net.
АХ>+1. Вот оно — благотворное влияние конкуренции.
Ш>>C++ же развивался под воздействием требований разработчиков, возникших не на пустом месте, и не вымученых из головы, а основаных на опыте практического применения. Результат налицо.
АХ>В результате сборная солянка.
Это твою личное неправильное мнение. С++ -- очень логичный и стройный язык. Если у тебя с ним проблемы -- это твои проблемы, а не языка.
АХ>Очень много чего напихали (и еще больше хотят) и теперь попробуй-ка напиши для этого дела компилятор.
Написать компилятор C++ -- не проблема.
АХ>Я уж не говорю, что он жутко медленным будет.
Почему то современные компиляторы C++ не являются жутко медленными. Опять врешь.
Здравствуйте, Шахтер, Вы писали:
АХ>>Я уж не говорю, что он жутко медленным будет.
Ш>Почему то современные компиляторы C++ не являются жутко медленными. Опять врешь.
К сожалению, если сравнивать, например, с компилятором D, то являются жутко медленными. Се ля ви.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, Константин Л., Вы писали:
АХ>>>В C++ даже нет такого базового свойства как рефлексия. Дальше можно не продолжать.
КЛ>>Хе-хе. Она мне в с# почти ни разу не пригодилась, не говоря уже о с++. Имхо рефлексия нужна там, где есть ошибки проектирования КЛ>> (сериализацию и т.п. в расчет не берем).
АХ>Почему не берем? Это одна из базовых и необходимейших задач, а ее значение в свете веб-сервисов еще важнее. А также сюда же AOP, Unit Tests и еще много других нужных и полезных технологий.
SOAP сериализация — да. Вэб-сервисы — частный случай. Поддержка AOP должна быть на уровне языка.
[]
АХ>COM — это кроссязыковая технология и при этом такой жутик, что MS пришлось сделать .NET. При этом собственно изначально .NET возник из проекта по добавлению метаданных к C++ (здесь), но в процессе оказалось что для полноценной компонентной технологии этого мало.
жутик? А может просто у некоторых людей проблемы с с++ и COM и им надо что-то попроще? Ну так пусть юзают что попроще, но к нам сюда не лезут.
Здравствуйте, Lorenzo_LAMAS, Вы писали:
WH>>Например компилятор nemerle. Написать его на С++ настолько сложная задача что справится с ней не сможет даже мелкософт с его гигабаксами. Меж тем на nemerle его ниписали два студента.
L_L>Ну-ну, вон три человека сумели компилятор С++ с экспортом шаблонов написать, да еще и на С. Наверное, справились бы и с немерле.
Сложность разработки C++ front-endа можно оценить в 10-12 человеко-лет. Back-enda -- ещё в столько же. Это вобщем небольшие проекты по современным меркам.
Кроме того, для проектов такого рода написание кода -- не самая большая проблема.
Усилий на проверку корректности поведения компилятора надо потратиь значительно больше, чем на его разработку.
С++, кстати, замечательно подходит для написания компиляторов, учитывая, что хороший компилятор содержит массу алгоритмически нетривиальных вещей.
Здравствуйте, Шахтер, Вы писали:
Ш>Усилий на проверку корректности поведения компилятора надо потратиь значительно больше, чем на его разработку.
Ну так на это тест-сьюты есть. EDG поименно называют, через что они свой фронтэнд прогнали. Бешеных денег стоят, кстати. Вот на разработчиков тестов и ляжет основная нагрузка при выходе нового стандарта, имхо.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Шахтер, Вы писали:
АХ>>>Я уж не говорю, что он жутко медленным будет.
Ш>>Почему то современные компиляторы C++ не являются жутко медленными. Опять врешь.
E>К сожалению, если сравнивать, например, с компилятором D, то являются жутко медленными. Се ля ви.
Языки разные. Кроме того, если ты не используешь "навороченные" библиотеки с матерноэтажными шаблонами типа boost, то скорость компиляции очень хорошая.
Основная причина низкой скорости компиляции больших С++ проектов -- это изобилие тяжелых заголовков. Хорошо помню, как сам избавлялся в старые добрые времена от iostream.h по этой причине.
К сожалению, современный С++ страдает библиотечной болезнью. Т.е. когда пишутся безразмерные библиотеки "общего назначения", которые однако оказываюся плохо приложимыми для решения конкретных задач. Как результат -- и компилируется медленно, и испольняется тоже. Да ещё и тянет мегабайты мертвого кода.
Повторное использование кода -- хорошая штука, но она не избавляет от необходимости думать.
Здравствуйте, Шахтер, Вы писали:
E>>К сожалению, если сравнивать, например, с компилятором D, то являются жутко медленными. Се ля ви.
Ш>Языки разные. Кроме того, если ты не используешь "навороченные" библиотеки с матерноэтажными шаблонами типа boost, то скорость компиляции очень хорошая.
Достаточно начать использовать хотя бы часть из STL (std::string, std::list, std::vector или std::set/map), то скорость компиляции уже заметно падает. А без STL я лично уже не хочу программировать на C++.
В то же время, компиляция библиотеки Mango (а это почти 200-ти файлов и больше 4Mb исходников) в release режиме занимает у меня на не очень мощном ноутбуке всего несколько (2-3) секунды. Очень впечатляет по первому разу. К тому же по своим возможностям D и C++ довольно-таки близки.
Ш>К сожалению, современный С++ страдает библиотечной болезнью. Т.е. когда пишутся безразмерные библиотеки "общего назначения", которые однако оказываюся плохо приложимыми для решения конкретных задач. Как результат -- и компилируется медленно, и испольняется тоже. Да ещё и тянет мегабайты мертвого кода.
Ага, а еще наровят все на шаблоннах сделать и совсем без cpp-файлов, чтобы каждый раз все перекомпилировалось...
Так что не смотря на довольно высокую скорость компиляции C++ файлов, есть и гораздо (очень гораздо) более быстро компилируемые языки. К сожалению для C++.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Константин Л., Вы писали:
КЛ>>>Хе-хе. Она мне в с# почти ни разу не пригодилась, не говоря уже о с++. Имхо рефлексия нужна там, где есть ошибки проектирования КЛ>>> (сериализацию и т.п. в расчет не берем).
АХ>>Почему не берем? Это одна из базовых и необходимейших задач, а ее значение в свете веб-сервисов еще важнее. А также сюда же AOP, Unit Tests и еще много других нужных и полезных технологий.
КЛ>SOAP сериализация — да. Вэб-сервисы — частный случай.
Да это для начала. Применений рефлексии еще полно. Да хотя бы нормальный вывод сообщений об ошибках. __FILE__, __LINE__ недостаточно.
КЛ>Поддержка AOP должна быть на уровне языка.
Уровень языка должен быть таким чтобы ее можно было безболезненно встроить с помощью подключаемой библиотеки. В этом помогут атрибуты.
АХ>>COM — это кроссязыковая технология и при этом такой жутик, что MS пришлось сделать .NET. При этом собственно изначально .NET возник из проекта по добавлению метаданных к C++ (здесь), но в процессе оказалось что для полноценной компонентной технологии этого мало.
КЛ>жутик? А может просто у некоторых людей проблемы с с++ и COM и им надо что-то попроще?
У самой MS с ним были проблемы, поэтому они и создали .NET.
Дело не в "попроще", а в "логичнее, надежнее и больше возможностей."
Для того, чтобы пользоваться COM мне еще надо всякие дурацкие нестандартные IDL-костыли вроде [in],[out] прикручивать, а потом пропускать через MIDL. Да и вообще даже с ATL с COM столько дурацкой тупой возни, да хотя бы с теми же GUIDами/CLSIDами, что застрелиться можно, а код замусорен макросами.
Ну и к тому же COM поддерживает очень малую часть возможностей C++.
Как мне с помощью COM любой стандартный контейнер типа std::vector передать ?
Или boost::lambda воспользоваться?
А могу ли я сделать шаблонную библиотеку?
Как насчет исключений?
КЛ> Ну так пусть юзают что попроще, но к нам сюда не лезут.
Мы уж лучше что помощнее. Попроще это к PHP-товарищам.
Здравствуйте, Андрей Хропов, Вы писали:
R>>Какие интересно задачи не позволяет решать С++? Имхо, если С++ сегодня не позволяет, то ни один язык сегодня не позволяет её решить.
АХ>В C++ даже нет такого базового свойства как рефлексия. Дальше можно не продолжать.
Это с каких это пор рефлексия — это базовое свойство?
Это все равно что в в каком-нть лохматом году начать говорить, что в Фортране нет такого базового свойства, как поддержки ООП.
Нормальная рефлексия характерна для современных языков да интерпретаторов типа TCL.
А метапрограммирование — штука сравнительно новая.
Хотя недооценивать ее, конечно же, нельзя, и комитет по стандартизации совершенно недвусмысленно указывает на свой интерес к ней (я процитирую, чтобы было яснее):
Not ready for C++09, but encourage work to continue
Papers in this category have been reviewed in EWG, and seen to solve real problems. While it is hoped that work will continue, they are not ready to be finalised in time for C++09. It is anticipated that this category will grow as time pressure restricts the feature list for C++09.
Reflective Metaprogramming in C++
Reflection in C++
Всего два пункта, и оба про рефлексию.
R>>Часто такими требованиями бывает портируемость не некую платформу, производительность, потребление памяти, доступ к аппаратному обеспечению, полный доступ к возможностям ос и т.д.
АХ>Это как раз к семантике (т.е. смыслу программы) никакого отношения не имеет. Это чисто технические подробности реализации.
а кто сказал, что требования к программам бывают толкьо семантическими? Наоборот, таких программ практически не бывает: все требуют чего-то специфического, и очень часто эти требования определяют язык разработки.
R>>Как бы это не было печально (или кому наоборот хорошо) и сегодня из-за семантической пропасти некое множество систем, написанных на языках _попроще_, или терпит крах или переписывается на С/С++...
АХ>Примеры?
У меня перед глазами прошло несколько экземпляров проприетарного банковского софта, в котором серверная часть была переписана с жавы на С++, обычно по соображениям производительности.
Ш>К сожалению, современный С++ страдает библиотечной болезнью. Т.е. когда пишутся безразмерные библиотеки "общего назначения", которые однако оказываюся плохо приложимыми для решения конкретных задач. Как результат -- и компилируется медленно, и испольняется тоже. Да ещё и тянет мегабайты мертвого кода.
Не согласен. В С++ (по крайней мере, современном) очень часто приходится выбирать между скорости компиляции и скоростью исполнения в run-time. К примеру, ты пишешь класс строк — можно описать весь интерфейс в заголовке а всю имплементацию вынести в cpp. Компилироваться будет быстро, но зато поимеешь накладные расходы в run-time как минимум за счёт того что фунции не будут заинлайнены.
Здравствуйте, remark, Вы писали:
R>Всё ясно R>Диплом/кандидатскую кто-то видимо защитил
Ничего тебе не ясно. Язык то развивается...
Уже и интеграция в студию работает лучше чем для С++. Подстказки для всего. Даже для кода сгенерированного макросами которые в немерле могут вобще все что можно сделать на платформе .НЕТ.
R>В общем несколько хватит фантации и какие требования.
Все эти способы я знаю и еще могу придумать... вот только нет способа такогоже простого, гибкого, надежного и масштабируемого как при использовании нормального метапрограммирования.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Еще раз перечитай мой первый пост в этой ветке. То сообщение на которое он был ответом. А потом перечитай свой пост.
Ведь ты же со мной согласен во всем кроме мелочей. Так что ты споришь?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Еще раз перечитай мой первый пост в этой ветке. То сообщение на которое он был ответом. А потом перечитай свой пост. WH>Ведь ты же со мной согласен во всем кроме мелочей. Так что ты споришь?
Главным образом я хочу получить ответ на свой вопрос:
R>>В-третьих, язык С++ очень мощный по выразительной мощности и по возможности абстрагироваться, и пакетировать функциональность (создавать повторноиспользуемые компоненты). По крайней мере из императивных языков.
WH>Раскажи это тем кто не пишет сложные кроссплатформенные системы на С++ ладно?
Вот тут не очень понял. Ты имеешь ввиду, что сложные кроссплатформенные системы нельзя писать на C++? Или что тем, кто не пишет сложных кроссплатформенных систем, C++ с его фичами не нужен?
поскольку твою фразу о разработке сложных кроссплатформенных систем я не понял
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, remark, Вы писали:
R>Никого же не удивляет, что очень сложно строить мосты и небоскрёбы.
Очень сложно на этапе проектирования — непосредственно делают опалубку и заливают бетон простые рабочие. И в строительстве (как, наверное, в любой другой отрасли) одно из направлений развития — именно упрощение элементарных операций.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Здравствуйте, remark, Вы писали:
R>Был свидетелем как переписывали с явы — не тянула требования работать на очень слабых машиных, которое вначале как-то не учли, а потом уже не смогли ничего сделать... R>С явы и шарпа, слышал, переписывают, когда по портируемости не тянет.
Ыы??? Что ты имеешь в виду под портируемостью? Код переписывают с языка, который исполняеться на виртуальной машине и имеет сборщик мусора, на какой-то другой язык для увеличения портируемости?? Если ты скажешь, что этот "другой язык" — это С++, мои мозги вообще закипят! Как можно на плюсах писать программы, которые лучше "тянут" по портируемости чем Жава/дотНет???
Сложность штука сложная... Вот, например, сделать работающую версию довольно большого проекта за один месяц — сложная задача? И что сразу хвататься за ассемблер? Я так думаю, для каждой задачи — свои инструменты. А приоритеты (ограниченные ресурсы) в проекте могут быть разные: качество, надежность, время разаботки, цена, количество программистов, производительность системы... И наверное, решить все одним и тем же топором не получится.
Здравствуйте, Gajdalager, Вы писали:
G>Если ты скажешь, что этот "другой язык" — это С++, мои мозги вообще закипят!
Мне жаль твои мозги, но им суждено закипеть.
Посмотри, например, на список поддерживаемых платформ для ACE. Есть ли JVM для всех этих платформ?
И насколько, скажем портируемы приложения J2SE на тот же J2ME?
G>Как можно на плюсах писать программы, которые лучше "тянут" по портируемости чем Жава/дотНет???
С некоторым напряжением, но можно.
А если нужно дергать специфические фичи целевой платформы, то C++ выгодно отличается от Java и тем более, от .NET.
Легче писать портируемые программы, разве что, только на C. Но еще вопрос, будет ли легкость портируемости компенсировать сложность самой разработки по сравнению с C++.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gajdalager, Вы писали:
G>Как можно на плюсах писать программы, которые лучше "тянут" по портируемости чем Жава/дотНет???
Это .NET портируемый? Ну портируйте кто нить что нить написанное хотяб под .NET 2.0 на линух.
Тогда как С++ проектов с никсов под вынь перетянуто множество.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
АХ>>Примеры?
J>У меня перед глазами прошло несколько экземпляров проприетарного банковского софта, в котором серверная часть была J>переписана с жавы на С++, обычно по соображениям производительности.
Ну я тоже видел этот софт — и мне лично кажется, что эти "соображения производительности" — фигня
на постном масле. Едва ли там делался сильно глубокий анализ узких мест и как их устранять. Как известно,
у любой задачи есть простое и неправильное решение.
Если бы решение было действительно взвешенным, то сначала бы на С++ переписали критические места,
и это при том, что не удалось их оптимизировать без переписывания. HotSpot у Java работает вполне неплохо.
А между тем, я не знаю, какие именно ты проекты имеешь ввиду, но я прекрасно помню один проект на С++, у
который то тёк, то коредампился, и так — в течение длительного срока.
И плоды видимо переписывания с джавы, когда внутри метода сервера выделяется память, присваивается
указателю, разыменовывается и возвращается ссылка — я тоже видел.,
Кстати, еще вопрос как оно там было с масштабируемостью вообще. Есть мнение — что никак.
Один известный мне проект на C++ преимуществом многопроцессорности пользовался весьма слабо —
являя собой несколько жирных практически монолитных бинарников, которые едва ли утилизировали
все мощности сервера, и почти никак не масштабировался на несколько серверов.
Что же касается производительности... В одном известном тебе операторе сотовой связи,
большинство серверного софта, даже в части, связанной с телефонией, было написано на языках
высокого уровня — на Java и, немного, на C#.
И оно работает быстро, и при очень высокой нагрузке. И, что самое главное, в случае, когда производительности начинает не хватать — ставится новый сервер, вместо переписывания всего на C++, потом на C, потом на ASM, потом ...
Кстати, есть один большой показательный пример — из соображений "производительности" одну большую систему реализовали поверх С++ middleware, который по стилю очень похож на одну очень хорошо известную тебе систему.
Так вот, в результате поимели: длительный период нестабильности софта, очень долгую (для подобного объема функционала) разработку, несколькикратное превышение сроков и бюджетов.
При этом конечный результат не является чем-то запредельным по производительности, на фоне других приложений, реализованных на Java. Возможно, для обслуживания равного количества запросов ему требуется на пару серверов меньше — но что такое эта пара серверов по сравнению с парой месяцев разработки...
J>С остальным согласен.
Здравствуйте, dmz, Вы писали:
dmz>А между тем, я не знаю, какие именно ты проекты имеешь ввиду, но я прекрасно помню один проект на С++, у dmz>который то тёк, то коредампился, и так — в течение длительного срока.
Да я смотрю тут вечер воспоминаний... Ну, я тож помню один проект на жаббе, который за пару лет разработки так и не научили работать с приемлемой скоростью и хавать не вообще всю свободную память.
dmz>Кстати, еще вопрос как оно там было с масштабируемостью вообще. Есть мнение — что никак.
Да, и не масштабировался он вообще никак. Даже удвоение оперативки от тормозов не спасло — он просто с радостно схавал дополнительную память и продолжил тормозюкать дальше. Заказчик был очень недоволен.
dmz>Один известный мне проект на C++ преимуществом многопроцессорности пользовался весьма слабо — dmz>являя собой несколько жирных практически монолитных бинарников, которые едва ли утилизировали dmz>все мощности сервера, и почти никак не масштабировался на несколько серверов.
Во во. Там тоже с этим не очень было. Просто в архитектуре масштабирование вообще никто не предусматривал. Да и софт был писан левой ногой.
dmz>В одном известном тебе операторе сотовой связи,
В городке N в компании M стоит софт, написанный на С== и который делает дело X. Так вот тот софт по производительности делает вообще всё, что когда либо писали и напишут
Настолько неаргументированно можно заявить вообще все что угодно.
dmz>... очень хорошо известную тебе систему.
Туды же... в качель, ага...
dmz>При этом конечный результат не является чем-то запредельным по производительности, на фоне других приложений, реализованных на Java.
Может просто надо было программистам руки выпрямить?
На любом языке можно писать плохо. Любую архитектуру можно спланировать наикривейшим способом. Язык то тут при чем?
Более того, приводя пример не мешало бы несколько конкретизировать и приводить хотя бы проверяемые данные. Потому как так можно написать все что угодно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
CC>В городке N в компании M стоит софт, написанный на С== и который делает дело X. Так вот тот софт по производительности делает вообще всё, что когда либо писали и напишут CC>Настолько неаргументированно можно заявить вообще все что угодно.
А что вам — названия компаний и проектов привести? Вам названия проектов что-то скажут?
Jazzer знает, о чем я говорю И что проект A***a в ******** Bank(это он был переписан с Java из соображений производительности?) тёк и дампился долгое время — тоже Посмотрим на его возражения.
dmz>>При этом конечный результат не является чем-то запредельным по производительности, на фоне других приложений, реализованных на Java. CC>Может просто надо было программистам руки выпрямить?
Ага — идите, выпрямляйте. Там как раз разработчиков C++ постоянно набирают, на этот проект как раз.
Хотите? Пишите в личку, выдам пароли и явки.
CC>На любом языке можно писать плохо. Любую архитектуру можно спланировать наикривейшим способом. Язык то тут при чем?
Мое утверждение: C++ не нужен для разработки серверов в 99.9% случаев. СУБД — это как раз оставшийся процент случаев. Разработка на нем дольше, сложнее, требует более высокой квалификации и не дает на этом классе задач никаких особенных преимуществ. С удовлетворением могу заметить, что эту точку зрения разделяют многие — например,
Ericsson.
Для системного программирования C++ тоже как-то не очень — что-то все больше С, тащить в ядра ОС или во встроенные устройства STL с boost пока решаются, видимо, только очень отдельные оригиналы.
Ну не страшно — ведь остается огромная ниша десктопного / прикладного софта, где относительно большая производительность и сравнительно небольшая прожорливость вполне себе факторы.
Врядли бы большинство пользователей были бы счастливы, если бы у них весь десктоп был написан на Java
Хотя с 2Gb памяти и 2GHz процами было бы нормально, наверное.
CC>Более того, приводя пример не мешало бы несколько конкретизировать и приводить хотя бы проверяемые данные. Потому CC>как так можно написать все что угодно.
Как вы собираетесь их проверять? Вам выдать исходники упомянутых проектов для самостоятельной сборки и проверки, что ли? Ну — какие подтверждения и чего именно нужны? Боюсь, что я могу только свидетелей привести.
Ну вот, например упомянутый мной пример С++ middleware. Очень красиво звучит — When High Performance Does Matter. На деле — 90% — маргетинговый буллщит, реальный опыт внедрения в одном из ведущих российских операторов сотовой связи — превышение сроков, бюджетов, огромная головная боль при разработке, долгий период нестабильности, дорогая поддержка — и в итоге всем ясно, что это уж никак не выигрывает у похожих по интенсивности и характеру нагрузке имеющихся решений на базе J2EE.
Нагрузка — десятки миллионов запросов в сутки и более. Казалось бы — high performance does matter, однако что-то не очень-то высокий перформанс тут — и аналогичные решения на Java, разработка и поддержка которых намного дешевле, справляются как минимум не хуже.
Кстати, хочу сказать, что я не призываю писать жесткий рилтайм на Java, однако же сомневаюсь, что его
пишут на C++.
Здравствуйте, dmz, Вы писали:
dmz>Кстати, хочу сказать, что я не призываю писать жесткий рилтайм на Java, однако же сомневаюсь, что его dmz>пишут на C++.
Таки пишут.
За счет того, что если C++ применять как C with classes, то писать на нем гораздо приятнее, чем на C.
А по поводу серверов -- в принципе согласен. Не зря же Java C++ в секторе server side значительно потеснила. Хотя в любой задаче есть свои исключения. И в большей степени качество и пр. параметры определяют не столько языки, сколько люди. А поскольку на подготовку нормального C++ программиста требуется гораздо больше времени и сил, то и результат получается соответствующий.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, dmz, Вы писали:
АХ>>>Примеры?
J>>У меня перед глазами прошло несколько экземпляров проприетарного банковского софта, в котором серверная часть была J>переписана с жавы на С++, обычно по соображениям производительности.
dmz>Ну я тоже видел этот софт — и мне лично кажется, что эти "соображения производительности" — фигня dmz>на постном масле. Едва ли там делался сильно глубокий анализ узких мест и как их устранять. Как известно, dmz>у любой задачи есть простое и неправильное решение. dmz>Если бы решение было действительно взвешенным, то сначала бы на С++ переписали критические места, dmz>и это при том, что не удалось их оптимизировать без переписывания. HotSpot у Java работает вполне неплохо.
я деталей не знаю, правда. Просто факт.
Ну и плюс в соседнем большом "фирмообразующем" проекте, о котором ты знаешь, ядро на плюсах, а гуй на жаве.
dmz>А между тем, я не знаю, какие именно ты проекты имеешь ввиду, но я прекрасно помню один проект на С++, у dmz>который то тёк, то коредампился, и так — в течение длительного срока.
dmz>И плоды видимо переписывания с джавы, когда внутри метода сервера выделяется память, присваивается dmz>указателю, разыменовывается и возвращается ссылка — я тоже видел.,
ну это вообще был код больных людей
dmz>Кстати, еще вопрос как оно там было с масштабируемостью вообще. Есть мнение — что никак. dmz>Что же касается производительности... В одном известном тебе операторе сотовой связи, dmz>большинство серверного софта, даже в части, связанной с телефонией, было написано на языках dmz>высокого уровня — на Java и, немного, на C#. dmz>И оно работает быстро, и при очень высокой нагрузке. И, что самое главное, в случае, когда производительности начинает не хватать — ставится новый сервер, вместо переписывания всего на C++, потом на C, потом на ASM, потом ...
все это — вопрос правильного проектирования, а не используемого языка. Если система сразу задизайнена по-человечески с расчетом на масштабируемость — она будет масштабируемой.
я вот сомневаюсь, что, скажем, гугль бегает на жаве.
Более того, я знаю фирмы, которые гоняют трафик, в чем-то сравнимый с сотовым — там все на С++ (преимущественно библиотека АСЕ плюс всякие бусты и прочая) — все летает и отлично масштабируется.
dmz>Один известный мне проект на C++ преимуществом многопроцессорности пользовался весьма слабо — dmz>являя собой несколько жирных практически монолитных бинарников, которые едва ли утилизировали dmz>все мощности сервера, и почти никак не масштабировался на несколько серверов.
Если мы говорим об одном и том же проекте — вспомни, в каком году он был написан
dmz>Кстати, есть один большой показательный пример — из соображений "производительности" одну большую систему реализовали поверх С++ middleware, который по стилю очень похож на одну очень хорошо известную тебе систему. dmz>Так вот, в результате поимели: длительный период нестабильности софта, очень долгую (для подобного объема функционала) разработку, несколькикратное превышение сроков и бюджетов.
У меня есть контрпример — С++-проект, который решили переписать на жаве (чтоб масштабируемость и прочая бла-бла-бла), который, по веселому совпадению, граничил (в смысле интерфейса) с жавным проектом, у которого ядро переписывают на С++. Так вот это переписывание должно было быть закончено два(!) года назад. Сейчас его худо-бедно пытаются заюзать, но там сейчас вопрос больше в том, чтоб оно наконец хоть как-то корнректно зароаботало, на то, что оно во сколько-то раз (точно не знаю) медленнее, чем древняя и морально устаревшая сиплюсовая версия — об этом даже никто и не задумывается пока.
R>We need relatively complex language to deal with absolutely complex problems.
R>Я с ним согласен.
Я с ним не согласен. Для решения сложных и запутанных задач нужен не сложный и запутанный язык, нужен мощный язык. Глупо отрицать, что C++ мощный язык. Но, во-первых, сегодня уже не самый мощный и выразательный, а, во-вторых, составляющая запутанности ограничивает его применение относительно оси сложности как снизу, так и сверху. Снизу порогом вхождения, сверху сложностью решения сложных задач.
R>То, что появится какой-то _простой_ язык, на котором можно будет научиться профессионально программировать на двух недельных курсах, и после этого создавать какие-то реальные приложения — это полная утопия и миф, который поддерживают компании, которые хотят впаривать якобы такие языки, и их поддерживают тупые менеждеры, которые верят, что они смогут понанимать дешёвых, неопытных программистов и таким образом достигнут высокой эффективности вложений.
Здесь я не согласен с тобой. Повторю ещё раз. Уровень решаемой сложности определяется не сложностью языка, а его мощностью и выразительностью. Простой язык вполне может быть одновременно и мощным, а для специализированных сложных задач вообще пишутся специализированные языки, многократно упрощающие решение этих задач.
R>Напоследок ещё одна цитата — просто очень понравиась:
R>
R>why do I see character echo delays in Word on my 2GHz, 2Gb computer? I didn’t see that on my editor on a shared 1MHz, 1Mb PDP11 25 years ago
А мне очень понравилось замечание WolfHound относительно этой цитаты
Угу вот только word написан на С/С++.
Если нам не помогут, то мы тоже никого не пощадим.
dmz>>Кстати, хочу сказать, что я не призываю писать жесткий рилтайм на Java, однако же сомневаюсь, что его dmz>>пишут на C++.
E>Таки пишут. E>За счет того, что если C++ применять как C with classes, то писать на нем гораздо приятнее, чем на C.
Ну а много ли при этом остается от великого и ужасного сложного C++ ? "C с классами" — это, считай, та-же Javа по сложности. Ну там, за вычетом управления памятью.
Это ли имеется ввиду под "сложным инструментом для сложных задач" ?
E>А по поводу серверов -- в принципе согласен. Не зря же Java C++ в секторе server side значительно потеснила.
"Значительно потеснила" это я боюсь, не совсем то выражение. Думаю, правильнее сказать, что в основном, кроме legacy-приложений.
E>Хотя в любой задаче есть свои исключения. И в большей степени качество и пр. параметры определяют не столько E>языки, сколько люди.
E>А поскольку на подготовку нормального C++ программиста требуется гораздо больше времени и сил, то и E>результат получается соответствующий.
Вот-вот, интересно, какой?
Варианты:
1) Пишется качественный и высокопроизводительный софт
2) Значительная часть кода пишется не "нормальными" С++ программистами?
3) Поскольку "нормальных" программистов днем с огнем не найдешь, и time-to-market проекта значительно увеличивается за счет поиска "нормальных", либо растут издержки на зарплаты, либо и то, и другое?
dmz>А что вам — названия компаний и проектов привести? Вам названия проектов что-то скажут? dmz>Jazzer знает, о чем я говорю И что проект A***a в ******** Bank(это он был переписан с Java из соображений производительности?) тёк и дампился долгое время — тоже Посмотрим на его возражения.
не, он изначально писался на плюсах. А вот другой, в котором не меньше важна производительность, был писан сразу дна жабе, и с производетльностью были большие проблемы, причем проблемы как раз типа так CreatorCray описал.
Только еще хуже — там сервер просто корился ( напоминаю, речь идет о жаве ).
Здравствуйте, CreatorCray, Вы писали:
dmz>>В одном известном тебе операторе сотовой связи, CC>В городке N в компании M стоит софт, написанный на С== и который делает дело X. Так вот тот софт по производительности делает вообще всё, что когда либо писали и напишут CC>Настолько неаргументированно можно заявить вообще все что угодно.
dmz>>... очень хорошо известную тебе систему. CC>Туды же... в качель, ага... CC>Более того, приводя пример не мешало бы несколько конкретизировать и приводить хотя бы проверяемые данные. Потому как так можно написать все что угодно.
Все нормально. dmz писал ссылался на то, что известно именно мне (см. выделенное)
Подтверждаю — он говорит правду, именно мне это известно, все правда.
Остальное — коммерческая тайна соответствующих (известных нам с dmz ) компаний.
Здравствуйте, dmz, Вы писали:
E>>Таки пишут. E>>За счет того, что если C++ применять как C with classes, то писать на нем гораздо приятнее, чем на C.
dmz>Ну а много ли при этом остается от великого и ужасного сложного C++ ? "C с классами" — это, считай, та-же Javа по сложности. Ну там, за вычетом управления памятью.
Как раз управления памятью в жестком real-time нет (по крайней мере по моему опыту). Память выделяется заранее и затем переиспользуется. Чтобы никакой new/delete в неподходящий момент не вмешался в работу.
А помогают как раз классы с деструкторами, вызывающимися в определенный и конкретный момент (RAII). Аргументы ссылки вместо указателей. Если есть возможность пользоваться шаблонами, то шаблоны позволяют упрощать код и не использовать макросы (хотя далеко не для всех экзотических real-time платформ есть шаблоны ).
dmz>Это ли имеется ввиду под "сложным инструментом для сложных задач" ?
Иногда работа с темпом даже в 100 миллисекунд бывает очень сложной задачей.
dmz>Вот-вот, интересно, какой?
Если в команде оказывается хотя бы один не очень опытный C++ разработчик, то плачевный.
dmz>Варианты:
dmz>1) Пишется качественный и высокопроизводительный софт dmz>2) Значительная часть кода пишется не "нормальными" С++ программистами? dmz>3) Поскольку "нормальных" программистов днем с огнем не найдешь, и time-to-market проекта значительно увеличивается за счет поиска "нормальных", либо растут издержки на зарплаты, либо и то, и другое?
Провокационные варианты
Естественно, что мной и моей командой пишется только качественный и высокпроизводительный софт. Я в этом даже не сомневаюсь
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
dmz>>Если бы решение было действительно взвешенным, то сначала бы на С++ переписали критические места, dmz>>и это при том, что не удалось их оптимизировать без переписывания. HotSpot у Java работает вполне неплохо. J>я деталей не знаю, правда. Просто факт.
Угу. Но решение "переписать все" — оно не свидетельствует о взвешенном и разумном подходе.
У Java есть JNI, критичные вещи можно было бы вынести туда. Хотя может быть исходный пример был
настолько крив, что ему помогло не столько переписывание на "С++", сколько переписывание вообще.
Зная местную специфику, согласись, это может быть правдой.
J>Ну и плюс в соседнем большом "фирмообразующем" проекте, о котором ты знаешь, ядро на плюсах, а гуй на жаве.
Ну да, про стабильность серверной части мы наслышаны Надеюсь, все стало хорошо — но заняло это не один год в итоге.
dmz>>И плоды видимо переписывания с джавы, когда внутри метода сервера выделяется память, присваивается dmz>>указателю, разыменовывается и возвращается ссылка — я тоже видел., J>ну это вообще был код больных людей
На Java был бы валидный код — о памяти позаботился бы GC
J>Более того, я знаю фирмы, которые гоняют трафик, в чем-то сравнимый с сотовым — там все на С++ (преимущественно J>библиотека АСЕ плюс всякие бусты и прочая) — все летает и отлично масштабируется.
Да не вопрос, что можно! Вопрос только, сколько это стоит и нужно ли это на самом деле.
J>на то, что оно во сколько-то раз (точно не знаю) медленнее, чем древняя и морально устаревшая сиплюсовая версия — J>об этом даже никто и не задумывается пока.
Здравствуйте, remark, Вы писали:
R>Ну а как насчёт, ну не знаю, доступа к регистрам аппаратуры, или "написания программы на машинном коде" (ну это когда ты пишешь программу на яву, но при этом фактически знаешь, что будет делать процессор).
Попробуй записать на C++ что-нибудь в порт под виндой, а я посмотрю
R>Пусть для чего-то мне понадобится в начале сделать свою библиотеку, и синтаксис будет не такой красивый. Но преград нет. В этом суть.
Преграда есть. Это ограниченность наших способностей. Чем сложнее иструмент, тем менее сложные задачи мы можем решать, т.к. часть наших усилий тратится на преодоление сложности иструмента. Столь же мощный, но более простой иструмент напротив позволяет высвобождать наш потенциал и направлять его на решение самой задачи.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Шахтер, Вы писали:
Ш>>Усилий на проверку корректности поведения компилятора надо потратиь значительно больше, чем на его разработку.
J>Ну так на это тест-сьюты есть.
Ага. Они самые. А ты прикинь, сколько усилий надо приложить, чтобы напридумывать разных головоломных ситуаций и понять, как они должны по стандарту обрабатываться. И это в C++ !
Поэтому они и стоят бешенных денег.
Здравствуйте, eao197, Вы писали:
E>За счет того, что если C++ применять как C with classes, то писать на нем гораздо приятнее, чем на C.
Да и существенная доля С++ проектов которые таки отличаются стабильностью и производительностью именно на С с классами + чуть чуть темплейтов пишутся. Остальные навороты в зоопарке зачастую не нужны.
Выскажу одно свое подозрение: чтоб прогер качественно писал на С++ ИМХО нужно чтобы он представлял как это все работает. В смысле: после компиляции.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, dmz, Вы писали:
CC>>На любом языке можно писать плохо. Любую архитектуру можно спланировать наикривейшим способом. Язык то тут при чем? dmz>Мое утверждение: C++ не нужен для разработки серверов в 99.9% случаев.
Ну, сервера серверам рознь. Есть сервера приложений, сервера баз а есть и сервера для обработки данных, которые на них поступают.
dmz>тащить в ядра ОС или во встроенные устройства STL с boost пока решаются, видимо, только очень отдельные оригиналы.
И слава те Господи! Если на STL еще не особо претензий накопилось то буст просто полный атас.
dmz>Как вы собираетесь их проверять? Вам выдать исходники упомянутых проектов для самостоятельной сборки и проверки, что ли?
Ну, тута я децл погорячился. Просто частое употребление фраз типа "в одном известном мне" создает впечатление придуманности, что ли.
dmz>Очень красиво звучит — When High Performance Does Matter. dmz>На деле — 90% — маргетинговый буллщит, реальный опыт внедрения в одном из ведущих российских операторов сотовой связи — превышение сроков, бюджетов, огромная головная боль при разработке, долгий период нестабильности, дорогая поддержка
А было бы все иначе (в лучшую сторону разумеется) если он был бы написан теми же людьми с той же архитектурой но на Java? Имхо не настолько там в языке дело. Просто на Java плохой код не приводит к таким последствиям как на С++.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Шахтер, Вы писали:
E>>>К сожалению, если сравнивать, например, с компилятором D, то являются жутко медленными. Се ля ви.
Ш>>Языки разные. Кроме того, если ты не используешь "навороченные" библиотеки с матерноэтажными шаблонами типа boost, то скорость компиляции очень хорошая.
E>Достаточно начать использовать хотя бы часть из STL (std::string, std::list, std::vector или std::set/map), то скорость компиляции уже заметно падает. А без STL я лично уже не хочу программировать на C++.
Тут вопрос не в STL даже, и не в шаблонах, а в пресловутой модели включения.
Представь, что у тебя 100 исходных файлов, каждый из которых включает некий заголовок MyCoolVector.h. И в каждом исходнике ты используешь MyCoolVector<int>. Как результат, при сборке проекта ты будешь этот класс инстантинировать 100 раз вместе с его методами, т.е. компилятор выполнит одну и ту же работу 100 раз, а потом ещё и линкеру придется разгребать эту кучу и выкидывать лишнее. Отсюда и скорость сборки.
Такая модель сложилась исторически.
Необходимо от неё отходить, для чего и в языке, и в его реализациях нужны определённые изменения.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Gajdalager, Вы писали:
G>>Как можно на плюсах писать программы, которые лучше "тянут" по портируемости чем Жава/дотНет??? CC>Это .NET портируемый? Ну портируйте кто нить что нить написанное хотяб под .NET 2.0 на линух. CC>Тогда как С++ проектов с никсов под вынь перетянуто множество.
В теории .Нет кроссплатформенный, а моноплатформенность .Нета происходит не от каких-либо просчетов в архитектуре или спецификации, а из-за политики МС.
Кроме того, при написании програм на Жаве(и, в теории, на .Нете), кроссплатформенность получаем сразу и без усилий.. Чтобы написать непортируемую программу, нужно постараться... С другой стороны, чтобы сохранить на плюсах портируемость на уровне исходников(не говоря уже про портируемость исполняемого кода), нужно постоянно учитывать это на этапе написания кода.
dmz>>Мое утверждение: C++ не нужен для разработки серверов в 99.9% случаев. CC>Ну, сервера серверам рознь. Есть сервера приложений, сервера баз а есть и сервера для обработки данных, которые CC>на них поступают.
При этом отличие серверов БД от прочих в том, что они:
1) Зачастую полностью определяют производительность систем, которые их используют
2) Сравнительно плохо кластеризуются
Из этого определенным образом следует, что при разработке серверов БД нам нужна вся
производительность до капли — это критично.
Но тут, внимание, вопрос — а на С++ ли они пишутся? Не на C ли, случаем?
dmz>>Как вы собираетесь их проверять? Вам выдать исходники упомянутых проектов для самостоятельной сборки и проверки, что ли?
CC>Ну, тута я децл погорячился. Просто частое употребление фраз типа "в одном известном мне" создает впечатление CC>придуманности, что ли.
Хоть я работаю в не в упомянутом банке и не в упомянутом-же сотовом операторе, не думаю, что упоминать их, особенно после рассказа о некоторых внутренних особенностях — этично.
Да и будет ли вам легче, если будете знать, очередной раз активируя скретч-карту или засовывая деньги в аппарат экспресс-оплаты, что ваши деньги поступают на счет почти исключительно молитвами тех. саппорта ?
CC>А было бы все иначе (в лучшую сторону разумеется) если он был бы написан теми же людьми с той же архитектурой но CC>на Java? Имхо не настолько там в языке дело. Просто на Java плохой код не приводит к таким последствиям как на CC>С++.
Думаю, было бы лучше. Главным образом потому, что существуют аналоги этого поделия, реализованные на J2EE и они работают вполне нормально. Аналог же этого я видел один, и он был так же крив, и проблемы с ним были очень похожие.
Здравствуйте, dmz, Вы писали:
dmz>Угу. Но решение "переписать все" — оно не свидетельствует о взвешенном и разумном подходе. dmz>У Java есть JNI, критичные вещи можно было бы вынести туда.
не все, а серверная часть (т.е. та, которая считает математику, и сам транспорт).
Остальное осталось на жабе.
dmz>Хотя может быть исходный пример был dmz>настолько крив, что ему помогло не столько переписывание на "С++", сколько переписывание вообще. dmz>Зная местную специфику, согласись, это может быть правдой.
Соглашусь, просто на всякий случай замечу, что это не зависит от языка
dmz>На Java был бы валидный код — о памяти позаботился бы GC
Вот как раз с GC и была проблема.
Он банально не успевал чистить память, в результате все корилось из-за нехватки памяти.
Явный вызов gc тоже не был вариантом из-за неизвестного времени работы (сам знаешь, что такое софт, занимающийся скоростной торговлей на бирже, и какова стоимость малейшей задержки в трансорте).
В этом смысле С++ на голову выше управляемых языков, именно тем, что, благодаря наличию в языке деструкторов, всегда точно известно, сколько у тебя чего, когда что освободилось, и т.п.
Причем даже если ты будешь использовать всякие системы со счетчиками ссылок типа boost::shared_ptr, когда неизвестно точно, в какой момент что умрет, известно, сколько времени может занять смерть (вызов деструктора) плюс известны возможные места смерти (т.е. места, где декрементится счетчик).
А в жабе он вызовется хз когда и будет работать хз сколько вреени, ты же не можешь ему сказать, что, мол, освободи мне мегабайт, чтоб можно было дальше работать, и уйди нафиг в тень...
J>>Более того, я знаю фирмы, которые гоняют трафик, в чем-то сравнимый с сотовым — там все на С++ (преимущественно J>библиотека АСЕ плюс всякие бусты и прочая) — все летает и отлично масштабируется.
dmz>Да не вопрос, что можно! Вопрос только, сколько это стоит и нужно ли это на самом деле.
Насколько я знаю, немного. Там сидят, по-моему, всего три реально высококвалифицированных программера на С++, и им этого вполне достаточно, проект развивается и приносит нехилые бабки.
J>>на то, что оно во сколько-то раз (точно не знаю) медленнее, чем древняя и морально устаревшая сиплюсовая версия — J>об этом даже никто и не задумывается пока.
dmz>Бывает
Вот о чем и речь. Что в 80% случаев не в языке дело.
Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>Ну-ну, вон три человека сумели компилятор С++ с экспортом шаблонов написать, да еще и на С. Наверное, справились бы и с немерле.
Нет, с Немерле не справились бы. Как бы они вывод типов написали бы? А вот компилятор C++ на Немерле написать — проще некуда. Только всё равно на 100% поддержку C++ сделать нельзя, как говорится, by design.
Здравствуйте, Шахтер, Вы писали:
Ш>С++, кстати, замечательно подходит для написания компиляторов, учитывая, что хороший компилятор содержит массу алгоритмически нетривиальных вещей.
Нет, как раз на ФЯ вроде Nemerle псать компиляторы проще. Вообще, алгоритмически нетривиальные вещи на C++ неудобно решать. А вот в ML-языках имеются алгебраические типы и паттерн матчинг, что позволяет банально меньше писать. И это, заметьте, влияет не только (и не столько) на скорость написания, но и на читабельность кода.
Здравствуйте, Шахтер, Вы писали:
E>>Достаточно начать использовать хотя бы часть из STL (std::string, std::list, std::vector или std::set/map), то скорость компиляции уже заметно падает. А без STL я лично уже не хочу программировать на C++.
Ш>Тут вопрос не в STL даже, и не в шаблонах, а в пресловутой модели включения.
+1
Ш>Представь, что у тебя 100 исходных файлов, каждый из которых включает некий заголовок MyCoolVector.h. И в каждом исходнике ты используешь MyCoolVector<int>.
Да ладно бы дело было в MyCoolVector. А то ведь просто напишешь в cpp-файле #include <string> и все -- время компиляции увеличилось на порядок
Ш>Такая модель сложилась исторически. Ш>Необходимо от неё отходить, для чего и в языке, и в его реализациях нужны определённые изменения.
Идеи есть какие-нибудь?
А то у меня они слишком радикальные -- использовать Scala и D вместо C++.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, konsoletyper, Вы писали:
K>Вообще, алгоритмически нетривиальные вещи на C++ неудобно решать.
Пример можно?
Именно алгоритмической нетривиальности (а то приводящиеся обычно в качестве демонстрации pattern matching-а разборы синтаксичеких конструций такими назвать довольно сложно).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>>Ну-ну, вон три человека сумели компилятор С++ с экспортом шаблонов написать, да еще и на С. Наверное, справились бы и с немерле.
K>Нет, с Немерле не справились бы. Как бы они вывод типов написали бы?
Интересно как вывод типов в продукте может зависеть от языка реализации этого продукта? По твоему трансляторы пролога тоже невозможно на C/C++ написать?
K>А вот компилятор C++ на Немерле написать — проще некуда. Только всё равно на 100% поддержку C++ сделать нельзя, как говорится, by design.
Gajdalager wrote: > В теории .Нет кроссплатформенный, а моноплатформенность .Нета происходит > не от каких-либо просчетов в архитектуре или спецификации, а из-за > политики МС.
Вообще-то, я уже как-то флеймил, что из-за некоторых предположений в
модели памяти .NET — его будет сложно портировать на nccNUMA-машины
(когда они появятся ).
Здравствуйте, Hobot Bobot, Вы писали:
R>>Никого же не удивляет, что очень сложно строить мосты и небоскрёбы.
HB>Очень сложно на этапе проектирования — непосредственно делают опалубку и заливают бетон простые рабочие.
Некорректная аналогия: роль "простых работяг", выполняющих элементарные действия, играют не программисты, а компилятор.
"Залить бетон" это как "перегнать вот эту функцию в машинный код" или типа того.
Программист всегда остается "проектировщиком".
HB>И в строительстве (как, наверное, в любой другой отрасли) одно из направлений развития — именно упрощение элементарных операций.
А в разработке ПО элементарные действия принято вообще автоматизировать
Здравствуйте, FR, Вы писали:
K>>Нет, с Немерле не справились бы. Как бы они вывод типов написали бы?
FR>Интересно как вывод типов в продукте может зависеть от языка реализации этого продукта? По твоему трансляторы пролога тоже невозможно на C/C++ написать?
Возмножно, но весьма сложно. В принципе, можно браться за любой сложности задачу, однако, когда сложность превышает все возможные пределы, можно сказать, что решить задачу невозможно (на самом деле, экономически невыгодно).
K>>А вот компилятор C++ на Немерле написать — проще некуда. Только всё равно на 100% поддержку C++ сделать нельзя, как говорится, by design.
FR>выделеннное
Такая же гипербола, как и выделенное ниже:
L_L>>>Ну-ну, вон три человека сумели компилятор С++ с экспортом шаблонов написать, да еще и на С. Наверное, справились бы и с немерле.
А вообще, рад, что развеселил. Смех продляет жизнь. Приятно сделать доброе дело
Здравствуйте, eao197, Вы писали:
K>>Вообще, алгоритмически нетривиальные вещи на C++ неудобно решать.
E>Пример можно?
Как показала моя личная практика, утилита, называемая compiler-compiler, даже на C# пишется гораздо проще, чем на C++. Сейчас экспериментирую с Nemerle. Уже полностью готовы синтаксический и семантический анализаторы входного файла. Вот, ИМХО, написание семантического анализатора и есть нетривиальная алгоритмическая задача. Отмечу, что входной файл для утилитки имеет гораздо более сложную структуру, чем входной файл для yacc. Там нужно обойти и проанализировать AST, сделать подстановки, проверить, чтобы не было рекурсивных подстановок. Потом генерируются совокупность регулярных выражений по описанию лексического анализатора и формальная КС-грамматика по описанию синтаксиса.
Тут можно возразить, что это сделает любой школьник и что есть же более сложные задачи — например, факторизация числа. Но тут рулит не С++ и даже не Nemerle, а метематика (а реализовать можно хоть на ассемблере, Кнут так и делает). Кстати, то же относится и к системе вывода типов в Nemerle. Правда, там есть как математическая составляющая, так и просто сожный в реализации алгоритм. Вот пример того, что на C++ решать неудобно.
E>Именно алгоритмической нетривиальности (а то приводящиеся обычно в качестве демонстрации pattern matching-а разборы синтаксичеких конструций такими назвать довольно сложно).
Всё познаётся в сравнении. Есть задачи, очень неудобно решаемые в императивном стиле, зато удобно решаемые в функциональном. Бывают задачи, обладающие обратным свойством. Очень хорошо, если язык позволяет легко и эффективно решать и тот и другой класс задач. Из известных мне языков таким полезным свойством обладают Nemerle и в меньшей степени Python и Lisp.
Здравствуйте, Alxndr, Вы писали:
A>Некорректная аналогия: роль "простых работяг", выполняющих элементарные действия, играют не программисты, а компилятор.
Однозначного отображения процесса строительства на процесс программирования нет и, ясен пень, быть не может. Впрочем, думаю, что между рядовым строителем и программистом, пишущим код по подробной спецификации, общего достаточно для проведения аналогий.
HB>>И в строительстве (как, наверное, в любой другой отрасли) одно из направлений развития — именно упрощение элементарных операций.
A>А в разработке ПО элементарные действия принято вообще автоматизировать.
Ну так и раствор нынче не лопатами замешивают. По крайней мере, если речь не идет о постройке погреба на даче.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Здравствуйте, konsoletyper, Вы писали:
K>>>Вообще, алгоритмически нетривиальные вещи на C++ неудобно решать.
E>>Пример можно?
K>Как показала моя личная практика, утилита, называемая compiler-compiler, даже на C# пишется гораздо проще, чем на C++. Сейчас экспериментирую с Nemerle. Уже полностью готовы синтаксический и семантический анализаторы входного файла. Вот, ИМХО, написание семантического анализатора и есть нетривиальная алгоритмическая задача. Отмечу, что входной файл для утилитки имеет гораздо более сложную структуру, чем входной файл для yacc. Там нужно обойти и проанализировать AST, сделать подстановки, проверить, чтобы не было рекурсивных подстановок. Потом генерируются совокупность регулярных выражений по описанию лексического анализатора и формальная КС-грамматика по описанию синтаксиса.
Реализацией compiler-compiler я сам когда-то занимался в свободное от работы время. На C++, естественно. Никакой алгоритмической сложности там не было -- просто был взят алгоритм генерации правил подстановки Флойда (выслушенный когда-то на курсе системного программирования в университете) и закодирован на C++. Самый сложный кусок -- выделение типов правил грамматики и генерация правил подстановки Флойда занимает всего около 700 строк. И сложности там нет, только объем за счет for-ов.
Так что пример мимо кассы.
Ладно бы вы приводили примеры из области расспознавания образов или речи. Говорят там действительно C++ (как, думаю и другие императивные языки) не у дел.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Андрей Хропов, Вы писали:
АХ> Очень много чего напихали (и еще больше хотят) и теперь попробуй-ка напиши для этого дела компилятор. Я уж не говорю, что он жутко медленным будет.
Самое забавное, что line-by-line компилятор от Microsoft для C++ быстрее, чем их же компилятор для C# Проблема компиляции C++ не столько в сложности языка, сколько в модели включения. Собственно, главный бич C++ и есть (включая проблемы ODR и т.п.). Благо, это понимает большое количество народу, и есть шансы, что дело исправится, возможно, даже до выхода следующего стандарта.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eao197, Вы писали:
K>>Как показала моя личная практика, утилита, называемая compiler-compiler, даже на C# пишется гораздо проще, чем на C++. Сейчас экспериментирую с Nemerle. Уже полностью готовы синтаксический и семантический анализаторы входного файла. Вот, ИМХО, написание семантического анализатора и есть нетривиальная алгоритмическая задача. Отмечу, что входной файл для утилитки имеет гораздо более сложную структуру, чем входной файл для yacc. Там нужно обойти и проанализировать AST, сделать подстановки, проверить, чтобы не было рекурсивных подстановок. Потом генерируются совокупность регулярных выражений по описанию лексического анализатора и формальная КС-грамматика по описанию синтаксиса.
E>Реализацией compiler-compiler я сам когда-то занимался в свободное от работы время. На C++, естественно. Никакой алгоритмической сложности там не было -- просто был взят алгоритм генерации правил подстановки Флойда (выслушенный когда-то на курсе системного программирования в университете) и закодирован на C++. Самый сложный кусок -- выделение типов правил грамматики и генерация правил подстановки Флойда занимает всего около 700 строк. И сложности там нет, только объем за счет for-ов.
Кстати, алгоритм получения канонической LR-системы вообще занимает менее 300 строк. Это далеко не самая сложная штука. Нужно распарсить и проанализировать входной файл (а это не так просто в моём случае). Нужно сгенерировать код. Можно ещё поэкспериментировать с нормальным error reporting в алгоритме LR, компиляцией магазинного автомата, автоматизированным построением AST и т.д. Собственно, есть уже формализованные алгоритмы построения КК и здесь главную роль играет не язык, а математика.
E>Ладно бы вы приводили примеры из области расспознавания образов или речи. Говорят там действительно C++ (как, думаю и другие императивные языки) не у дел.
Тут тоже математика, языки ни при чём. Однако, думаю, для таких задач есть свои языки (Lisp, Prolog и т.д.), на которых реализация будет читабельнее
WolfHound, это сюда слил чтобы было удобнее ногами это дело бить? Или чтобы бригада была по ударнее?
А воооще, с идей то как раз можно согласиться. Конечно примитивный язык вряд ли хорош для решения сложных задач. Но вот С++ язык не сложный, а не интуитивный и запутанный. А это, как говорят в Одессе, две большие разницы.
К тому же термин "сложный" не очень хорошо здесь подходит. Я бы его заменил на выразительный.
Так что если фразу заменить на:
"Для решения сложных задач нужен выразительный и гибкий язык.", то я бы с удовольствием под ней подписался. Только С++ отнюдь не выразителен и не так гибок как хотелось бы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
КЛ>а то я вас не знаю
Люди меняюстя. Меняюстя их привычки и привязанности. Откровенно говоря после занкомства с Nemerle смысл в использовании C# я вижу исключительн из-за того, что у него лучше поддержка в разного рода визардах, технологиях и IDE.
Если в сравнении с C# 2.0 С++ и может еще что-то противопоставить, то в сравнении с Nemerle он сливает по всем пунктам кроме скорости и потреблению памяти в конечных приложениях. Но и тут он не так уж и сильно впереди. И что самое главное с ростом производительности железа и оттачичанием технологий С++ становится все менее и мее актуальным.
В области, прикладного программирования в С++ уже сосем мало тлка. Скоро очередь дойдет и до относительно системного ПО. Первыми будут компиляторы и IDE, а там и до всяких вордов не далеко.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, remark, Вы писали:
R>Какие интересно задачи не позволяет решать С++? Имхо, если С++ сегодня не позволяет, то ни один язык сегодня не позволяет её решить.
Ой, всего лишь одну. Писать надежный и хорошо читаемый код.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Например компилятор nemerle. Написать его на С++ настолько сложная задача что справится с ней не сможет даже мелкософт с его гигабаксами. Меж тем на nemerle его ниписали два студента.
Да ладно тебе. С мегабаксами можно все. Можно и на ассемблере его написать. Создадут отдел планирования, распишут все на фунции по 20 байт. Потом создадут по департаменту для кодирования каждой фичи и в итоге получат нужный результат. Ну, лет так за 5.
Конечно это будет сопоставимо с тем, что два студента могут залудить за 3 года на другом средсве, но все же более чем возможно.
WH>И больше всего у них проблем возникает с ошибками в CLR который сам понимаешь кем и начем написан. А ведь мелкософт может позволить себе нанять элиту.
Видили мы код их элиты.
WH>Что уж говорить о конторах помельче...
А вот это да. Думаю, не видать нам РеШарпера как своих ушей если бы его пришлось писать на С++.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, remark, Вы писали:
WH>>>>А для абсолютно сложных задач нужно что-то попроще и помощьнее. R>>>Под complex он подразумевает не сложный (как алгоритм), а скорее комплексный. Т.е. некая real-world задача с неким абсолютно непредсказуемым набором нефункциональных требований, и которые могут непредсказыемым образом эволюционировать. WH>>И как тут поможет С++?
R>У него нет семантической пропасти.
Ой, так любопытно. Объясни, плиз, что такое "семантическая пропасть"?
Если можно, с примерами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
R>Copyright (c) 2003, 2004 The University of Wroclaw.
R>Всё ясно R>Диплом/кандидатскую кто-то видимо защитил
Это еще что... Прикинь, а Страуструп PhD на С++ заработал.
R>А если серьёзно, то — да как хочешь она будет выглядеть. R>Есть просто надо ограниченный набор структур сериализовать — то просто перечислением полей в функции сериализации. R>Если сериализовать действительно много — то можно подумать о генераторе кода — perl/самописный/готовый — asn.1 или ещё что-то. R>Можно препроцессор подпрячь. R>Можно описать список полей на template metaprogramming, тогда получится compile-time рефлекшн. R>Можно ввести базовые классы для классов и полей, что б автоматически собирать информацию о структуре. R>... R>В общем несколько хватит фантации и какие требования.
Понятно. Ты молодец. Твоя фантазия очень правильно работает. Главное не использовать для этого сам С++. Потому как получится, ну, очень запутанно и неудобно. +100
Ради хомхмы, попробуй любыми перечисленными тобой средствами сделать так чтобы можно было просто пометить тип (один из тысячи) каким-то образом как сериализуемый, и чтобы автоматом, при компиляции, создался код сериализации для всего на что этот тип ссылается (потентциально для всей тысячи классов).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, konsoletyper, Вы писали:
L_L>> Ну-ну, вон три человека сумели компилятор С++ с экспортом шаблонов написать, да еще и на С. Наверное, справились бы и с немерле.
K> Нет, с Немерле не справились бы. Как бы они вывод типов написали бы?
Повторно использовали бы код, делающий то же самое для операнда sizeof() и перегрузки функций?
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eao197, Вы писали:
E>Главным образом я хочу получить ответ на свой вопрос: E>
E>Вот тут не очень понял. Ты имеешь ввиду, что сложные кроссплатформенные системы нельзя писать на C++? Или что тем, кто не пишет сложных кроссплатформенных систем, C++ с его фичами не нужен?
E>поскольку твою фразу о разработке сложных кроссплатформенных систем я не понял
Мне кажется, он имел в виду, что на С++ очень сложно писать переносимый код. Сложно потому, что стандарт реально почти никем не реализован. Сложно потому, что сложно качесвтенно портировать компиляторы. Сложно потому что много UB. Сложно потому, что язык в угоду оптимизации создает массу сложностей вроде платформно-зависимых типов...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Пример можно? E>Именно алгоритмической нетривиальности (а то приводящиеся обычно в качестве демонстрации pattern matching-а разборы синтаксичеких конструций такими назвать довольно сложно).
Мне кажется замечательным примером могут являться компиляторы Ди и Немерле. Их фронтэнды примерно равны по объему, но по возможностям различюатся в разы. По времени написания тоже. Ди раза в два-три страше.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
КЛ>хм...Издеваешься? Нормальный человек бы описание хоть привел, что тут должно делаться. И то, что ты его не привел — твоя проблема. И не удивляйся, что нико не захочет тебе на это отвечать.
Ну, нормальный человек и так прочесть может . Здесь очевидно разбирается некий язык токены которого лежат в списке decls.
VladD2 wrote: > Мне кажется, он имел в виду, что на С++ очень *сложно* писать > переносимый код. Сложно потому, что стандарт реально почти никем не > реализован. Сложно потому, что сложно качесвтенно портировать > компиляторы. Сложно потому что много UB. Сложно потому, что язык в угоду > оптимизации создает массу сложностей вроде платформно-зависимых типов...
Да ну, не серьезно. Если хочется портируемости — пишем под GCC, который
есть даже для тостеров и чайников. Этого достаточно для всех
практических целей.
Обычный "С с классами" и умеренным использованием шаблонов тоже вполне
нормально переносится.
Здравствуйте, Cyberax, Вы писали:
C>Да ну, не серьезно. Если хочется портируемости — пишем под GCC, который C>есть даже для тостеров и чайников. Этого достаточно для всех C>практических целей.
А ты прочти рядом интервью Тененбаума. Он как раз говорит "пишите на С без расширений... стандарты... стандарты...".
C>Обычный "С с классами" и умеренным использованием шаблонов тоже вполне C>нормально переносится.
Намного сложенее чем просто С.
C>Главные проблемы, как обычно, с библиотеками.
Если перенесен компилятор С, то все библиотеки тоже перенесены. Их у него довольно мало.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>Да ну, не серьезно. Если хочется портируемости — пишем под GCC, который > C>есть даже для тостеров и чайников. Этого достаточно для всех > C>практических целей. > А ты прочти рядом интервью Тененбаума. Он как раз говорит "пишите на С > без расширений... стандарты... стандарты...".
Так зачем расширения использовать? Просто при использовании GCC будет
примерно одинаковый набор багов компилятора на всех системах.
> C>Обычный "С с классами" и умеренным использованием шаблонов тоже вполне > C>нормально переносится. > Намного сложенее чем просто С.
Уже вполне нормально — все вполне работает, если не учитывать совсем уж
убитые компиляторы. У меня есть опыт по переносу нескольких программ на
С++ между системами — проблем с САМИМ языком не было почти никаких.
> C>Главные проблемы, как обычно, с библиотеками. > Если перенесен компилятор С, то все библиотеки тоже перенесены. Их у > него довольно мало.
Вот в этом и проблема — для реального приложения нужны внешние
библиотеки, а вот они как раз часто вообще не переносятся. С .NET
ситуация, кстати, точно такая же.
На самом деле, Страуструп просто исказил идею.
Еще дедушка Брукс писал, что сложность бывает "естественная" и "добавочная". Естественная сложность — это та, которая присуща предметной области, понятиями которой оперирует специалист в этой самой предметной области. Добавочная стоимость — это та, которая связана с внутренней организацией компилятора языка и оси (опосредствованно, через библиотеки).
Вполне очевидно, что сложность конструкций языка должна быть адекватна естественной сложности решаемых задач.
И так же вполне нетрудно сообразить, что присущие С++ сложности ковыряния стека через va_arg или возни с попытками убрать детали реализации из h-файлов не имеют к сложности предметной области ни малейшего отношения.
AndreiF wrote: > Вполне очевидно, что сложность конструкций языка должна быть адекватна > естественной сложности решаемых задач.
А еще бывает ПРАКТИЧЕСКАЯ сложность.
Сложность С++ не в сложности самого языка, а в количестве базовых
понятий. В той же Java есть только константы, объекты и примитивы, а в
С++ есть: константа, указатель, массив, ссылка, автоматический объект
(встроенные и свои типы), умный указатель.
Поэтому С++ предоставляет такие фичи, которых просто НЕТ в
Nemerle/Java/C#. Соответственно, он может решать задачи, которые на
практике на Nemerle/Java/C# не решаются.
Спор о необходимости этих фич — это уже отдельный флейм.
Здравствуйте, konsoletyper, Вы писали:
K>Кстати, алгоритм получения канонической LR-системы вообще занимает менее 300 строк. Это далеко не самая сложная штука. Нужно распарсить и проанализировать входной файл (а это не так просто в моём случае). Нужно сгенерировать код. Можно ещё поэкспериментировать с нормальным error reporting в алгоритме LR, компиляцией магазинного автомата, автоматизированным построением AST и т.д. Собственно, есть уже формализованные алгоритмы построения КК и здесь главную роль играет не язык, а математика.
Собственно об этом и речь, что к "алгоритмической сложности" C++ не имеет отношения.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
E>>Главным образом я хочу получить ответ на свой вопрос: E>>
E>>Вот тут не очень понял. Ты имеешь ввиду, что сложные кроссплатформенные системы нельзя писать на C++? Или что тем, кто не пишет сложных кроссплатформенных систем, C++ с его фичами не нужен?
E>>поскольку твою фразу о разработке сложных кроссплатформенных систем я не понял
VD>Мне кажется, он имел в виду, что на С++ очень сложно писать переносимый код.
Я бы хотел услышать ответ из первоисточника.
Поскольку твое мнение, по крайней мере на моем опыте, не имеет ничего общего с действительностью.
VD>Сложно потому, что стандарт реально почти никем не реализован.
Весь стандарт в подавляющем большинстве случаев и не нужен.
Не всегда даже нужна поддержка специализаций шаблонов, не говоря уже о частичной специализации.
VD>Сложно потому, что сложно качесвтенно портировать компиляторы.
Сколько некачественных C++ компиляторов, когда и на каких платформах тебе доводилось видеть или использовать. И сколько в это же время и на этих же платформах было компиляторов с отличных от C/C++ языков?
VD>Сложно потому что много UB.
Это к портируемости вообще имеет косвенное отношение.
VD>Сложно потому, что язык в угоду оптимизации создает массу сложностей вроде платформно-зависимых типов...
Платформенно-зависимые типы не являются проблемой даже если требуется организовывать обмен данными между различными платформами.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
AndreiF wrote: > C>Соответственно, он может решать задачи, которые на > C>практике на Nemerle/Java/C# не решаются. > Он предоставляет возможность делать низкоуровневые оптимизации, которые > нельзя сделать в Nemerle/Java/C#. Но оптимизации — это не задачи.
Это НЕ оптимизации. Это примитивы, которых нет в C#/... Они могут, в том
числе, быть использованы и для оптимизации.
Кстати, оптимизация — сама по себе тоже вполне задача, которая переводит
практические задачи из категории "невозможные" в "возможные".
Здравствуйте, Cyberax, Вы писали:
C>Это НЕ оптимизации. Это примитивы, которых нет в C#/... Они могут, в том C>числе, быть использованы и для оптимизации.
А помимо этого? Приведи реальный пример, плиз. Что (кроме оптимизаций) можно сделать на С++, чего нельзя сделать на C#?
C>Напишешь Quake4 на Питоне?
На самом деле, большая (по объему) часть современных игр пишется как раз на скриптах, в том числе и Питоне. Эта часть как правило больше, чем часть кода написанного на С++. Так что вопрос можно поставить и обратный — а ты напишешь Quake 4 на чистом С++?
Здравствуйте, VladD2, Вы писали:
R>>Какие интересно задачи не позволяет решать С++? Имхо, если С++ сегодня не позволяет, то ни один язык сегодня не позволяет её решить. VD>Ой, всего лишь одну. Писать надежный и хорошо читаемый код.
Все зависит от квалификации человека. Плохой и нечитабельный код можно написать практически на любом более менее серьезном ЯП
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Gajdalager, Вы писали:
G>В теории .Нет кроссплатформенный, а моноплатформенность .Нета происходит не от каких-либо просчетов в архитектуре или спецификации, а из-за политики МС.
Ну, то что в теории можно выбросить сразу — интересует только практика. Какой смысл от того что он в теории кроссплатформенный когда на практике это использовать нельзя? Когда в этом плане что либо изменится — тогда можно говорить о кроссплатформенности. А покуда — .NET НЕ кроссплатформенный.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, AndreiF, Вы писали:
C>>Напишешь Quake4 на Питоне? AF>На самом деле, большая (по объему) часть современных игр пишется как раз на скриптах
AF>Эта часть как правило больше, чем часть кода написанного на С++.
AF> Так что вопрос можно поставить и обратный — а ты напишешь Quake 4 на чистом С++?
Да.
В том же Q4 скрипты предназначены только для того, чтобы можно было быстро и просто менять игровую логику не пересобирая движок.
Ничто в общем то не мешает весь этот код запихать в DLL как это было во времена того же HL.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
AF>> Так что вопрос можно поставить и обратный — а ты напишешь Quake 4 на чистом С++? CC>Да. CC>В том же Q4 скрипты предназначены только для того, чтобы можно было быстро и просто менять игровую логику не пересобирая движок. CC>Ничто в общем то не мешает весь этот код запихать в DLL как это было во времена того же HL.
Смелый парень. И много квейков 4, или хотя бы ХЛов ты за свою жизнь написал?
AndreiF wrote: > C>Это НЕ оптимизации. Это примитивы, которых нет в C#/... Они могут, в том > C>числе, быть использованы и для оптимизации. > А помимо этого? Приведи реальный пример, плиз. Что (кроме оптимизаций) > можно сделать на С++, чего нельзя сделать на C#?
Написать Q4. В теории это возможно хоть на Brainf**k, но на
практике только С++.
> C>Напишешь Quake4 на Питоне? > На самом деле, большая (по объему) часть современных игр пишется как раз > на скриптах, в том числе и Питоне. Эта часть как правило больше, чем > часть кода написанного на С++. Так что вопрос можно поставить и обратный > — а ты напишешь Quake 4 на *чистом* С++?
А почему нет? Вот Q3 на С написан, а скрипты там — это просто входные
данные.
А ты напишешь ВЕСЬ Q4 на Питоне? Ведь оптимизация — это не задача.
Здравствуйте, konsoletyper, Вы писали:
FR>>Интересно как вывод типов в продукте может зависеть от языка реализации этого продукта? По твоему трансляторы пролога тоже невозможно на C/C++ написать?
K>Возмножно, но весьма сложно. В принципе, можно браться за любой сложности задачу, однако, когда сложность превышает все возможные пределы, можно сказать, что решить задачу невозможно (на самом деле, экономически невыгодно).
В чем сложность то? Мне кажется ты сильно преувеличиваешь то упрощение которое дают для данного класса задач ML подобные языки. Если бы ты был прав, то компиляторя уже очень давно писались бы только на чем то ML подобном например на Ocaml.
K>>>А вот компилятор C++ на Немерле написать — проще некуда. Только всё равно на 100% поддержку C++ сделать нельзя, как говорится, by design.
FR>>выделеннное
K>Такая же гипербола, как и выделенное ниже:
Нету там внизу никакой гиперболы.
L_L>>>>Ну-ну, вон три человека сумели компилятор С++ с экспортом шаблонов написать, да еще и на С. Наверное, справились бы и с немерле.
K>А вообще, рад, что развеселил. Смех продляет жизнь. Приятно сделать доброе дело
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, Cyberax, Вы писали:
C>>Написать Q4. В теории это возможно хоть на Brainf**k, но на C>>практике только С++.
AF>шейдеры тоже на С++ написаны?
Обычно на специализированном си подобном языке.
Кстати в подобных Q4 шутерах скрипты обычно очень мало используются.
Здравствуйте, eao197, Вы писали:
E>Идеи есть какие-нибудь? E>А то у меня они слишком радикальные -- использовать Scala и D вместо C++.
Идеи давно есть, проблема в претворении их на практике.
Ну, кстати, пресловутый экспорт шаблонов будучи должным образом реализованный мог бы помочь делу.
Здравствуйте, Cyberax, Вы писали:
C>AndreiF wrote: >> C>Это НЕ оптимизации. Это примитивы, которых нет в C#/... Они могут, в том >> C>числе, быть использованы и для оптимизации. >> А помимо этого? Приведи реальный пример, плиз. Что (кроме оптимизаций) >> можно сделать на С++, чего нельзя сделать на C#? C>Написать Q4. В теории это возможно хоть на Brainf**k, но на C>практике только С++.
Где-то я видел ссылки на порты Doom-а написанные на Java-е...
вполне играбельные...
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, Шахтер, Вы писали:
Ш>>С++, кстати, замечательно подходит для написания компиляторов, учитывая, что хороший компилятор содержит массу алгоритмически нетривиальных вещей.
K>Нет, как раз на ФЯ вроде Nemerle псать компиляторы проще. Вообще, алгоритмически нетривиальные вещи на C++ неудобно решать.
Здравствуйте, Шахтер, Вы писали:
Ш>Идеи давно есть, проблема в претворении их на практике.
Вот-вот. И, боюсь, реализуют их уже после того, как я перестану программировать
Ш>Ну, кстати, пресловутый экспорт шаблонов будучи должным образом реализованный мог бы помочь делу.
Или же какая-то более продвинутая форма precompiled headers.
Помнится в Turbo Pascal была система unit-ов, которые компилировались и записывались в tpu-файлы.
Для C/C++, в принципе, можно кроме объектных файлов для каждого исходника еще какой-то прекомпилированный файл строить -- объемы винчестеров и их сейчас это позволяют.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Gajdalager, Вы писали:
G>>В теории .Нет кроссплатформенный, а моноплатформенность .Нета происходит не от каких-либо просчетов в архитектуре или спецификации, а из-за политики МС. CC>Ну, то что в теории можно выбросить сразу — интересует только практика. Какой смысл от того что он в теории кроссплатформенный когда на практике это использовать нельзя? Когда в этом плане что либо изменится — тогда можно говорить о кроссплатформенности. А покуда — .NET НЕ кроссплатформенный.
Вообще-то я на дотНете не работаю, но, насколько я знаю, под Линукс есть Моно и дотГну. Как говорят на РСДНе, в Моно есть все, что есть в 1.1 кроме ВинФорм. Т.о. .Нет 1.1 все-таки кросплатформенный за небольшим исключением.. Более того, переносимость тут обеспечена на уровне бинарного кода, в отличие от плюсов.
Думаю, если бы МС вложила в развитие Моно (или даже своего собственного порта .Нета под Линукс) хотя бы половину денег, которые вложила в разработку платформы под винду, то можно было бы говорить о реальной кросплатформенности без исключений. Почему не делают? А невыгодно им... С другой стороны, в Жавы есть реальная кросплатформенность, с этим, думаю, не поспоришь. Кроме Жавы и .Нета, есть еще языки, которые используют виртуальную машину и сборщика мусора, к примеру Перл и Руби. Они тоже реально кросплатформенные, причем опять таки, разработчик не применяет особых усилий к сохранению переносимости.. В плюсах же ВМ и ГЦ нет, и переносимость сохраняеться ценой усилий(больших или нет — говорить не буду, т.к. реального опыта у меня тут нет).
На засыпочку. Сколько времени тебе нужно убить, чтобы скомпилировать и запустить код, отлично портируемый между Win-32 и Linux, на 64-битную архитектуру?
Здравствуйте, Gajdalager, Вы писали:
G>Кроме Жавы и .Нета, есть еще языки, которые используют виртуальную машину и сборщика мусора, к примеру Перл и Руби. Они тоже реально кросплатформенные, причем опять таки, разработчик не применяет особых усилий к сохранению переносимости..
Ну-ну. Попробуй к примеру поюзать popen3 одновременно под Windows и Unix
G>В плюсах же ВМ и ГЦ нет, и переносимость сохраняеться ценой усилий(больших или нет — говорить не буду, т.к. реального опыта у меня тут нет).
Наличие VM и GC к переносимости имеет очень косвенное отношение.
Гораздо важнее соответствие компилятора и библиотек стандартам. А наличие библиотек еще важнее.
G>На засыпочку. Сколько времени тебе нужно убить, чтобы скомпилировать и запустить код, отлично портируемый между Win-32 и Linux, на 64-битную архитектуру?
Здравствуйте, VladD2, Вы писали:
VD>Люди меняюстя. Меняюстя их привычки и привязанности. Откровенно говоря после занкомства с Nemerle смысл в использовании C# я вижу исключительн из-за того, что у него лучше поддержка в разного рода визардах, технологиях и IDE.
А как же пачка багов, которые nikov обнаружил в компиляторе только-только начав с ним работать?
Страшно подумать, что выплыло бы, если бы он попытался использовать его в продакшн-е.
Здравствуйте, Константин Л., Вы писали:
КЛ>Однако корреляция м/у сложность ю мощность все же существует. Имхо.
в смысле с ростом сложности растет и мощность языка? Не уверен. Вспомним статью Путеводитель автостопщика по потаенным знаниям
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
J>>А метапрограммирование — штука сравнительно новая.
VD>
Ты не согласен? Старая? И когда же метапрограммирование начало рассматриваться и применяться как полноценный метод программирования наряду с другими? До рождения С++?
Только не надо говорить, что метапрограммирование появилось, как только появился первый интерпретатор с командой eval (вообще говоря, тут и eval не нужен — ты можешь просто сгенерить из своего скрипта рядом файл с новым кодом и позвать его — чем не метапрограммирование).
Здравствуйте, remark, Вы писали:
R>Здравствуйте, MasterZiv, Вы писали:
MZ>>jazzer пишет: >>> The whole committee expressed a strong desire to deliver the next C++ >>> Standard in 2009.
MZ>>Зачем догружать и без того уже офигенно сложный язык ? MZ>>Может уже пора делать из него новый ?
R>Вот здесь Страуструп очень интересно пишет на этот счёт. Дядька хоть уже и старый, но всё ещё умный
<...> R>Я с ним согласен. То, что появится какой-то _простой_ язык, на котором можно будет научиться профессионально программировать на двух недельных курсах, и после этого создавать какие-то реальные приложения — это полная утопия и миф, который поддерживают компании, которые хотят впаривать якобы такие языки, и их поддерживают тупые менеждеры, которые верят, что они смогут понанимать дешёвых, неопытных программистов и таким образом достигнут высокой эффективности вложений.
<...>
Да ладно уж!
Этот изобретатель ничего другого не изобрёл, кроме монструозного и неоднозначного C++.
Зачем с ним соглашаться, если обычные офисные работники изучают VBA на двухнедельных курсах и прекрасно автоматизируют свои дела (в США)?
Кто скажет, что знает C++ "от и до", пусть кинет в меня камень.
"Тупые" менеджеры не разбираются в языках программирования, но они двигают дело наилучшим образом, на какое только способны только они, а не программисты. Они видят перспективу развития, принимают судьбоносные решения для своего бизнеса, управляют людьми.
И то, что сложный язык не нашёл горячей поддержки о "тупых" менеджеров, а остался в той нише, где он, скорее всего, останется навсегда, говорит о многом: за двадцать три года язык C++ не стал доминирующим языком высокого уровня, поскольку универсальность ведёт к сложности, а людям нужно решать конкретные узкоспециализированные задачи с быстрым обучением и быстрой отдачей. И они решают их не на C++.
Здравствуйте, iZEN, Вы писали:
ZEN>И то, что сложный язык не нашёл горячей поддержки о "тупых" менеджеров, а остался в той нише, где он, скорее всего, останется навсегда, говорит о многом: за двадцать три года язык C++ не стал доминирующим языком высокого уровня, поскольку универсальность ведёт к сложности, а людям нужно решать конкретные узкоспециализированные задачи с быстрым обучением и быстрой отдачей. И они решают их не на C++.
А не напомните, какой язык был доминирующим языком высокого уровня десять лет назад? Хотя бы на x86 платформе?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, jazzer, Вы писали:
J>Ты не согласен? Старая? И когда же метапрограммирование начало рассматриваться и применяться как полноценный метод программирования наряду с другими? До рождения С++?
Думаю, что где-то в района рождения Lisp-а, а может и раньше
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>Ты не согласен? Старая? И когда же метапрограммирование начало рассматриваться и применяться как полноценный метод программирования наряду с другими? До рождения С++?
E>Думаю, что где-то в района рождения Lisp-а, а может и раньше
Ага, для программирования искуственного интеллекта в университетах
В то время рулили всякие алголы и фортраны и прочие PL/1
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, VladD2, Вы писали:
VD>>Люди меняюстя. Меняюстя их привычки и привязанности. Откровенно говоря после занкомства с Nemerle смысл в использовании C# я вижу исключительн из-за того, что у него лучше поддержка в разного рода визардах, технологиях и IDE.
L>А как же пачка багов, которые nikov обнаружил в компиляторе только-только начав с ним работать?
Там не столько баги (хотя они тоже есть), сколько тонкие неопределенные моменты.
L>Страшно подумать, что выплыло бы, если бы он попытался использовать его в продакшн-е.
Ну если многие использовали (и используют) VC++ 6.0 который абсолютно не соответствует стандарту C++, имеет реализацию STL, в которой течет память, и частенько ICEится, то чему удивляться.
Я пописал на Nemerle и реальных showstopperов не заметил.
Здравствуйте, jazzer, Вы писали:
J>>>Ты не согласен? Старая? И когда же метапрограммирование начало рассматриваться и применяться как полноценный метод программирования наряду с другими? До рождения С++?
E>>Думаю, что где-то в района рождения Lisp-а, а может и раньше
J>Ага, для программирования искуственного интеллекта в университетах
J>В то время рулили всякие алголы и фортраны и прочие PL/1
Понятие "рулили" очень абстрактное. То, что большинство программистов в то время выполняли свою работу не на Lisp-е вовсе не означает, что на лиспе вообще не делалось важных и ответственных проектов. Думаю, что таки делались и метапрограммирование при этом использовалось на полную катушку.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, iZEN, Вы писали:
ZEN>>И то, что сложный язык не нашёл горячей поддержки о "тупых" менеджеров, а остался в той нише, где он, скорее всего, останется навсегда, говорит о многом: за двадцать три года язык C++ не стал доминирующим языком высокого уровня, поскольку универсальность ведёт к сложности, а людям нужно решать конкретные узкоспециализированные задачи с быстрым обучением и быстрой отдачей. И они решают их не на C++.
E>А не напомните, какой язык был доминирующим языком высокого уровня десять лет назад? Хотя бы на x86 платформе?
Здравствуйте, remark, Вы писали:
R>Вот, что из он заключает из этого:
We need relatively complex language to deal with absolutely complex problems.
Вообще-то аналогичная фраза (что-то вроде: "сложные задачи требуют сложных решений") была сказана задолго до Страуструпа одним из создателей языка Ада в ответ на вопрос Никлауса Вирта зачем же его понадобилось делать таким сложным.
По моему, за одну такую фразу программисту надо руки отрывать или, по крайней мере, увольнять ибо "СЛОЖНОСТЬ = УЯЗВИМОСТЬ".
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, Cyberax, Вы писали:
C>>Написать Q4. В теории это возможно хоть на Brainf**k, но на C>>практике только С++.
AF>шейдеры тоже на С++ написаны?
Мимо кассы, на питоне шейдеры тоже ни пишутся. Есть специальный язык для написания шейдеров с С подобным синтаксисом, его года 2 назад кажись стандартизировали.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, jazzer, Вы писали:
J>>А метапрограммирование — штука сравнительно новая.
АХ>Да, всего лет 50 существует .
Ага, а высшая математика существует со времен парадоксов Зенона.
Давайте не заниматься демагогией.
Когда метапрограммирование начало использоваться промышленно? Как методология, типа структурного, или ООП? Когда метапрограммированию стало уделяться в университетах столько же времени, как структурному или ООП? Когда оно стало магистральным направлением, каким последний лет 20 является ООП?
Имхо, до последнего времени (до 90-х) оно было больше игрушкой, чем реально и осознанно применявшимся методом программирования, со своими идиомами, методологиями.
Шаблоны в С++ тоже вон были давно, но применяться для метапрограммирования и программирования в функциональном стиле они стали совсем недавно, а до этого они использовались где-то на уровне eval в скриптах. Согласись же, eval никогда не был основным инструментом в скриптах, там всегда рулил стандартный процедурный подход, хотя все знали, что eval под боком.
Что-то Вы, уважаемый, преувеличиваете. Не надо думать, что все считают, что С++ можно запихнуть везде. Инструкции шейдеров довольно сложны, а учитывая, что требуется оптимизировать с учетом ТИПОВ и КОНВЕЙЕРОВ. Шейдеры пишутся на DSL языках, т.к. их нельзя использовать для разработки других программ и в них встроены особенности работы с видеокартой.
Скриптовые языки введены в разработку игр по одной причине — распределение разработки, т.е. те кто будет писать скрипты, т.е. это могут быть даже не высококвалифицированные программисты, т.е. язык должен быть проще и в нем должен быть доступ только к игровым объектам. При этом разработка может проходить параллельно и изменения не будут влиять на основной модуль.
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, CreatorCray, Вы писали:
CC>>Хе хе. Шейдеры можно успешно на NVAsm писать. Или на CG
AF>Но на С++ нельзя, верно?
А ты знаешь что такое шейдеры? И почему для них используют специальные языки?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, iZEN, Вы писали:
ZEN>>>И то, что сложный язык не нашёл горячей поддержки о "тупых" менеджеров, а остался в той нише, где он, скорее всего, останется навсегда, говорит о многом: за двадцать три года язык C++ не стал доминирующим языком высокого уровня, поскольку универсальность ведёт к сложности, а людям нужно решать конкретные узкоспециализированные задачи с быстрым обучением и быстрой отдачей. И они решают их не на C++.
E>>А не напомните, какой язык был доминирующим языком высокого уровня десять лет назад? Хотя бы на x86 платформе?
Ш>С ?
Высокого уровня?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Вообще-то аналогичная фраза (что-то вроде: "сложные задачи требуют сложных решений") была сказана задолго до Страуструпа одним из создателей языка Ада в ответ на вопрос Никлауса Вирта зачем же его понадобилось делать таким сложным.
Хех, как Вы хитро сюда к разговору Вирта прикрутили, это намек на Оберон? Его простота в отсутствии "Синтаксического оверхеда"?
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>>>Ты не согласен? Старая? И когда же метапрограммирование начало рассматриваться и применяться как полноценный метод программирования наряду с другими? До рождения С++?
E>>>Думаю, что где-то в района рождения Lisp-а, а может и раньше
J>>Ага, для программирования искуственного интеллекта в университетах
J>>В то время рулили всякие алголы и фортраны и прочие PL/1
E>Понятие "рулили" очень абстрактное. То, что большинство программистов в то время выполняли свою работу не на Lisp-е вовсе не означает, что на лиспе вообще не делалось важных и ответственных проектов. Думаю, что таки делались и метапрограммирование при этом использовалось на полную катушку.
У меня таких данных нет. У тебя есть? Я имею в виду, количество проектов на язык (а лучше — на методику, потому что тот же С++ можно использовать как С с классами, а можно — на полную катушку). Очень интересно посмотреть, в каком году в каком проценте проектов использовалось метапрограммирование (имхо, сейчас количество таких проектов быстро растет и почти не зависит от задачи, если только она не совсем уж тупая типа разбрасывания контролов по форме).
Вот мое (строго имховое) ощущение — метапрограммирование начинает рулить только сейчас, когда уже достаточно развились и заматерели функциональные языки, потому что оно обычно на них реализуется в том или ином виде.
Если бы метапрограммирование действительно рулило в то время, как рулило ООП, Страуструп бы ставил целью не только поддержку ООП, но и поддержку метапрограммирования (и все другие языки в то время — тоже. А уж после — тем более). Однако ничего такого не было. И жава тоже создавалась без единой мысли о метапрограммировании, была только базовая рефлексия, а это язык гораздо более новый, чем С++.
J>Когда метапрограммирование начало использоваться промышленно?
Smalltalk-80? 80 — это год, если я правильно понимаю? Smalltalk же — промышленный язык?
J>Как методология, типа структурного, или ООП? Когда метапрограммированию стало уделяться в университетах столько же J>времени, как структурному или ООП? Когда оно стало магистральным направлением, каким последний лет 20 является J>ООП?
В принципе, кодогенерация это тоже, в некотором роде, метапрограммирование. А лет кодогенерации лет наверное немногим меньше, чем программированию.
J>Имхо, до последнего времени (до 90-х) оно было больше игрушкой, чем реально и осознанно применявшимся методом программирования, со своими идиомами, методологиями.
90ые — это не совсем последнее время, все-таки.
J>Шаблоны в С++ тоже вон были давно, но применяться для метапрограммирования и программирования в функциональном стиле они стали совсем недавно,
"Применяться для программирования в функциональном стиле" — это ты имеешь ввиду Александреску "Язык шаблонов в C++ — чисто функциональный язык, программы на котором выполняются во время компиляции.",
или реализуемые при их помощи функциональные примочки в стиле boots::lambda?
J>а до этого они использовались где-то на уровне eval в скриптах. Согласись же, eval никогда не был основным J>инструментом в скриптах, там всегда рулил стандартный процедурный подход, хотя все знали, что eval под боком.
Думаю, это просто особенности восприятия. Судя по описаниям курса CS в MIT, метапрограммирование — это боян... то есть классика CS.
И возможности метапрограммирования в C++ шаблонах — достаточно ограничены.
J>>Когда метапрограммирование начало использоваться промышленно?
dmz>Smalltalk-80? 80 — это год, если я правильно понимаю? Smalltalk же — промышленный язык?
Ну, я не помню там особого метапрограммирования. Рефлексия — да, была.
И потом, ну какой это промышленный язык? Когда количество проектов на нем хотя бы приближалось к количеству ООП-проектов на других ООП-языках?
J>>Как методология, типа структурного, или ООП? Когда метапрограммированию стало уделяться в университетах столько же J>времени, как структурному или ООП? Когда оно стало магистральным направлением, каким последний лет 20 является J>ООП?
dmz>В принципе, кодогенерация это тоже, в некотором роде, метапрограммирование. А лет кодогенерации лет наверное немногим меньше, чем программированию.
Метапрограммирование — это руление кодом программы из самого кода на этом же языке в той же самой программе.
А кодогенерация — это кодогенерация, у нее свое место.
Как и у рефлексии.
Вот когда они объединяются и работают в рамках той же программы — это метапрограммирование.
J>>Имхо, до последнего времени (до 90-х) оно было больше игрушкой, чем реально и осознанно применявшимся методом программирования, со своими идиомами, методологиями.
dmz>90ые — это не совсем последнее время, все-таки.
Вполне последнее, для меня, по крайней мере. Скажем, в 90-е появилась джава — и где в ней поддержка метапрограммирования, раз оно так рулило до 90-х? Или хотя бы программые заявления на тему, что в след. версии все будет?
J>>Шаблоны в С++ тоже вон были давно, но применяться для метапрограммирования и программирования в функциональном стиле они стали совсем недавно,
dmz>"Применяться для программирования в функциональном стиле" — это ты имеешь ввиду Александреску "Язык шаблонов в C++ — чисто функциональный язык, программы на котором выполняются во время компиляции.",
dmz>или реализуемые при их помощи функциональные примочки в стиле boots::lambda?
А какая разница? И там, и там метапрограммирование.
И Александреску совсем не был первым извращенцем, кстати
J>>а до этого они использовались где-то на уровне eval в скриптах. Согласись же, eval никогда не был основным J>инструментом в скриптах, там всегда рулил стандартный процедурный подход, хотя все знали, что eval под боком.
dmz>Думаю, это просто особенности восприятия. Судя по описаниям курса CS в MIT, метапрограммирование — это боян... то есть классика CS.
По количеству часов, отводимых на него, и количеству программистов, выпускавшихся специалистами по метаязыкам — что ,столько же ,сколько по С/С++/VB?
dmz>И возможности метапрограммирования в C++ шаблонах — достаточно ограничены.
Никто и не говорит, что они безграничны.
Если бы это было не так, не было бы такой цитаты со странички комитета: http://www.rsdn.ru/Forum/Message.aspx?mid=2324384&only=1
Здравствуйте, SiAVoL, Вы писали:
SAV>Здравствуйте, Константин Л., Вы писали:
КЛ>>Однако корреляция м/у сложность ю мощность все же существует. Имхо. SAV>в смысле с ростом сложности растет и мощность языка? Не уверен. Вспомним статью Путеводитель автостопщика по потаенным знаниям
J>Ты не согласен? Старая? И когда же метапрограммирование начало рассматриваться и применяться как полноценный метод программирования наряду с другими? До рождения С++?
Конечно, ключевое слово макроассемблер.
J>Только не надо говорить, что метапрограммирование появилось, как только появился первый интерпретатор с командой eval (вообще говоря, тут и eval не нужен — ты можешь просто сгенерить из своего скрипта рядом файл с новым кодом и позвать его — чем не метапрограммирование).
Не только, в том же форте макро вполне в стиле немерле (вернее наооборот).
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, dmz, Вы писали:
J>>>Когда метапрограммирование начало использоваться промышленно?
J>Ну, я не помню там особого метапрограммирования. Рефлексия — да, была.
Согласно источникам, там еще были метаклассы.
J>И потом, ну какой это промышленный язык? Когда количество проектов на нем хотя бы приближалось к количеству J>ООП-проектов на других ООП-языках?
А какие еще в 80-х были ООП языки? И каково было вообще количество проектов? Есть подозрение, что
сильно меньше, чем сейчас.
dmz>>В принципе, кодогенерация это тоже, в некотором роде, метапрограммирование. А лет кодогенерации лет наверное немногим меньше, чем программированию.
J>Метапрограммирование — это руление кодом программы из самого кода на этом же языке в той же самой программе. J>А кодогенерация — это кодогенерация, у нее свое место.
С тобой согласны не все:
Metaprogramming is the writing of programs that write or manipulate other programs (or themselves) as their data or that do part of the work that is otherwise done at runtime during compile time. This allows programmers to produce a larger amount of code and get more done in the same amount of time as they would take to write all the code manually.
Да и из практических соображений, велика ли разница — сам язык предоставляет средства манипулирования порождаемым кодом, или внешний тул? Вот взять С — препроцессор, там, конечно, часть языка — но больших проблемах написать препроцессоров на чем угодно и использовать их — нет. Какая разница при этом? Родной препроцессор в принципе, сильно отличается от языка в целом. То же можно и сказать о шаблонах — они, согласно стандарту, часть языка — но при этом сильно отличаются от остального языка. Это целая новая концепция, с другими выразительными средствами и даже подходом.
J>А какая разница? И там, и там метапрограммирование. J>И Александреску совсем не был первым извращенцем, кстати
Ну разница где-то в том, что вычисление факториала числа в компайл-тайме
практически бесполезно, несмотря на то, что реализовано при помощи "метапрограммирования".
J>По количеству часов, отводимых на него, и количеству программистов, выпускавшихся специалистами по метаязыкам — J>что ,столько же ,сколько по С/С++/VB?
По количеству часов, честно говоря, не знаю. Знаю только, что в MIT CS учили с чего-то вроде схемы, по пути реализовав ее интерпретатор в рамках курса. А VB в штатах учат таксистов, на недельных курсах.
Здравствуйте, Gajdalager, Вы писали:
G>Т.о. .Нет 1.1 все-таки кросплатформенный за небольшим исключением.
Нельзя быть немного беременной. Или кроссплатформ или нет. Иначе получается кросс только для негуевых прог.
G>Думаю, если бы МС вложила в развитие Моно (или даже своего собственного порта .Нета под Линукс) хотя бы половину денег, которые вложила в разработку платформы под винду
Ага щаззз...
G>С другой стороны, в Жавы есть реальная кросплатформенность, с этим, думаю, не поспоришь.
В те древние времена когда я работал в жабовом проекте с кроссплатформенностью там были проблемы. И это на чисто бизнес проекте где ничего HW specific не было. Правда давно это было ...
G>В плюсах же ВМ и ГЦ нет
И это является плюсом плюсов.
G>На засыпочку. Сколько времени тебе нужно убить, чтобы скомпилировать и запустить код, отлично портируемый между Win-32 и Linux, на 64-битную архитектуру?
Чью 64 битную? Win/Lin?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, dr.Chaos, Вы писали:
DC>>Мимо кассы, на питоне шейдеры тоже ни пишутся.
AF>Я и без тебя знаю. Спор вообще не об этом.
А о чем?
Шейдеры тут вообще не к месту. Они пишутся на своем специализированном языке и точка, ни С++, ни пайтон тут не причем.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, jazzer, Вы писали:
J>Ты не согласен? Старая? И когда же метапрограммирование начало рассматриваться и применяться как полноценный метод программирования наряду с другими? До рождения С++?
Впервые термин квази-цитирование был введен известным специалистом в области логики Уиллардом Куини в 1940 году. Куин использовал квази-цитирование для конструирования выражений математической логики. И первым языком, использующим, механизм квази-цитирования стал Lisp разработанный Джоном Маккарти примерно в 1960 году, но внедрен в язык и начал применяться только с середины 70-х годов.
(с) мой, отрывок из моей работы
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, CreatorCray, Вы писали:
CC>>На любом другом кстати тоже...
AF>Это уже отельный вопрос. А факт — это то, что универсальность плюсов сильно преувеличивают. И никакого Q4 "на чистом С++" никто не напишет.
А шейдеры тут причем?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, jazzer, Вы писали:
J>У меня таких данных нет. У тебя есть? Я имею в виду, количество проектов на язык (а лучше — на методику, потому что тот же С++ можно использовать как С с классами, а можно — на полную катушку). Очень интересно посмотреть, в каком году в каком проценте проектов использовалось метапрограммирование (имхо, сейчас количество таких проектов быстро растет и почти не зависит от задачи, если только она не совсем уж тупая типа разбрасывания контролов по форме).
Я не Lisp-ер, поэтому не знаю, где поискать информацию аналогичную Common Lisp Success Stories для Lisp-а тех времен. Но думаю, что применения Lisp-а в реальной работе были. Ведь Common Lisp развился и начал использоваться отнюдь не на пустом месте.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Plague, Вы писали:
AF>>Но на С++ нельзя, верно?
P>Что-то Вы, уважаемый, преувеличиваете. Не надо думать, что все считают, что С++ можно запихнуть везде. Инструкции шейдеров довольно сложны, а учитывая, что требуется оптимизировать с учетом ТИПОВ и КОНВЕЙЕРОВ.
P>Шейдеры пишутся на DSL языках, т.к. их нельзя использовать для разработки других программ и в них встроены особенности работы с видеокартой.
На самом деле видеокарты проходят тот же путь повышения абстракции: сначала был NVasm, потом специализированные языки Cg, HLSL, GLSL, а теперь вот уже можно обычный C
(правда там хитро — часть работы производится на CPU, часть на GPU).
P>Скриптовые языки введены в разработку игр по одной причине — распределение разработки, т.е. те кто будет писать скрипты, т.е. это могут быть даже не высококвалифицированные программисты, т.е. язык должен быть проще и в нем должен быть доступ только к игровым объектам. При этом разработка может проходить параллельно и изменения не будут влиять на основной модуль.
Плохо то, что они (скрипты), как правило интерпретируются. В принципе перспективный подход — это их JIT компиляция. И некоторые уже так и делают — вот например в небезызвестной игре Second Life для скриптов потихоньку пытаются встроить рантайм Mono:здесь.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>У меня таких данных нет. У тебя есть? Я имею в виду, количество проектов на язык (а лучше — на методику, потому что тот же С++ можно использовать как С с классами, а можно — на полную катушку). Очень интересно посмотреть, в каком году в каком проценте проектов использовалось метапрограммирование (имхо, сейчас количество таких проектов быстро растет и почти не зависит от задачи, если только она не совсем уж тупая типа разбрасывания контролов по форме).
E>Я не Lisp-ер, поэтому не знаю, где поискать информацию аналогичную Common Lisp Success Stories для Lisp-а тех времен. Но думаю, что применения Lisp-а в реальной работе были. Ведь Common Lisp развился и начал использоваться отнюдь не на пустом месте.
Я сразу, понятное дело, ткнулся в музыку — ссылки не работают, вот облом
Понятно, что не на пустом месте. Понятно, что был Яху (не знаю, что там за лисп использовался, но это 90-е уже, если не позже), и Буч очень хорошо отзывался о CLOS, и я после прочтения его книжки страсть как захотел его изучить.
Так же как и функциональные языки — я вот считал диссер на Математике, там такая помесь функционального и императивного — и мне сильно не хватало в плюсах функциональных возможностей.
Но все равно в последнее время рулил ООП, а до него — структурщина. Естественно, были изыскания и эксперименты в стороне от мэйнстрима, если бы их не было, не было бы сейчас взлета функциональных языков и метапрограммирования.
В общем, я свое имхо озвучил
Заодно смотри мой ответ Трурлю.
В общем, я не могу сразу всем отвечать одно и то же, давайте я буду где-нть в одном месте
Прощу прохения заранее
Здравствуйте, AndreiF, Вы писали:
AF>Это уже отельный вопрос. А факт — это то, что универсальность плюсов сильно преувеличивают. И никакого Q4 "на чистом С++" никто не напишет.
Пардон, но ИМХО ты уже ушел не в ту степь. Сам Q4 на С++ написать реально. Кста он на нем то и написан. А вот все окружение — графику, шейдера, звук и прочее — это отдельно.
Кстати поскольку тобой был использован чуть ли не самый популярный прием демагогии — доведение до абсурда, то с чистой совестью вешаю ярлык: вы сударь — демагог!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, jazzer, Вы писали:
J>И потом, ну какой это промышленный язык? Когда количество проектов на нем хотя бы приближалось к количеству ООП-проектов на других ООП-языках?
Не надо подменять понятия. К чему эти впадения в среднетяжмаш? Речь шла не о промышленности а о новизне — и в этом смысле метапрограммирование скорее всего старее, чем ООП.
Первые пакеты символьной математики были написаны на Lisp, а значит, и с использованием метапрограммирования. Это как, серьезные проекты?
Софт для Space Shuttle — по некоторым данным самое надежное и дорогое ПО всех времен и народов — был написан в том числе и на DSL-диалекте PL/1. Это нормальный проект?
Или пока каждый комбайнер на селе не начнет без устали метапрограммировать, изобретение не засчитывается? Так тогда метапрограммирование не просто ново, а еще не изобретено.
... << RSDN@Home 1.2.0 alpha rev. 655>>
'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
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, jazzer, Вы писали:
J>>И потом, ну какой это промышленный язык? Когда количество проектов на нем хотя бы приближалось к количеству ООП-проектов на других ООП-языках?
K>Не надо подменять понятия. К чему эти впадения в среднетяжмаш? Речь шла не о промышленности а о новизне — и в этом смысле метапрограммирование скорее всего старее, чем ООП.
нет, изначально речь не о новизне, а о том, что это была общеизвестная базовая вещь во времена создания С++.
K>Первые пакеты символьной математики были написаны на Lisp, а значит, и с использованием метапрограммирования. Это как, серьезные проекты? K>Софт для Space Shuttle — по некоторым данным самое надежное и дорогое ПО всех времен и народов — был написан в том числе и на DSL-диалекте PL/1. Это нормальный проект?
Вполне серьезные и нормальные. Но технология мейнстримовой не была.
K>Или пока каждый комбайнер на селе не начнет без устали метапрограммировать, изобретение не засчитывается? Так тогда метапрограммирование не просто ново, а еще не изобретено.
ну не надо извращать мой тезис. Я не хочу флейма. См. мой пост Трурлю.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, jazzer, Вы писали:
J>>В то время рулили всякие алголы и фортраны и прочие PL/1
Т>Кстати. Макросы PL/1 — чем не метапрограммирование?
Ну и макросы макроассемблера тоже
давайте все же разделим, что мы считаем метапрограммированием, а что — нет.
Иначе любой язык может служить примером метапрограммируемого, если он умеет писать на диск файлы и вызывать для них компилятор, а потом запускать скомпилированную программу (кто сказал, что программа — это только один бинарник?) или динамически загружать собранную таким образом библиотеку.
Для меня лично идеальный язык, поддерживающий метапрограммирование — это язык, в который встроен API к компилятору.
Т.е. который имеет доступ ко всему, что имеет компилятор, и, соответственно, может анализировать это как угодно, генерить на основе этого код (более общо — сущности, которыми оперирует компилятор, включая типы, код и еще чего-нть, атрибуты, скажем) и инжектировать его в любое место дерева инструкций, системы типов и т.п.
Чтобы можно было на самом языке определять, что такое — класс (скажем, что в нем генерится по умолчанию, а что — нет, как именно работает определенное отношение между классами, начиная с простейших — наследование, агрегация, делегирование и т.п.) и т.п.
Т.е. чтобы он, грубо говоря, торчал где-то между фронт-эндом и бэк-эндом компилятора и мог делать все, что только можно себе вообразить на этом месте и с этой информацией. Иными словами, язык программирования компилятора.
Вот в таком виде метапрограммирование, я считаю, дошло до промышленной кондиции только сейчас (вернее, еще не дошло, но необходимость этого ясно осознана). И сейчас есть четкое понимание, что любой язык в том или ином виде должен это содержать. Именно поэтому сейчас почти все языки движутся в этом направлении — и С++, и жава, и шарп.
Я считаю, что раньше (т.е. во времена создания С++, да и Java тоже) этого понимания не было. Тогда еще с ООП толком не разобрались (несмотря на то, что основополагающие работы был сделаны в 50-60х, типа Лисков и прочих). Развитие ООП, на мой взгляд, более-менее завершилось с формулировкой дизайн-паттернов.
В общем, изначальный тезис, к которому тут прицепились и раздули флейм, сводится к простой вещи — некорректно говорить, что в С++ нет такой базовой вещи, как рефлексия, ибо то, что это действительно базовая вещь (т.е. необходимая в _каждом_ промышленном языке, в том числе и в императивном), а не просто экзотика, осознано очень недавно. Если бы все промышленные языки того времени умели рефлексировать и это использовалось бы в почти каждой программе — тогда да, упрек был бы по адресу. Но так не было.
Вот если бы в С++ не было поддержки ООП — такой упрек был бы корректным. Потому что в то время было четкое понимание, что языки должны поддерживать ООП в том или ином виде.
Естественно, я говорю про индустрию программирования, а не про науку — она, понятное дело, всегда впереди и обычно немного не о том. С++ создавался для решения реальных задач и проблем, стоявших перед индустрией того времени. Имхо, рефлексия и заодно метапрограммирование тогда в списке насущных проблем не значились.
Здравствуйте, CreatorCray, Вы писали:
CC>Пардон, но ИМХО ты уже ушел не в ту степь. Сам Q4 на С++ написать реально. Кста он на нем то и написан. А вот все окружение — графику, шейдера, звук и прочее — это отдельно.
Мда. Бедный С++ — с одной стороны его притесняют совсем уж низкоуровневые языки, с другой скрипты. Но все равно кому-то еще хватает совести заявлять, что "на самом то деле бОльшая часть на С++ пишется"
CC>Кстати поскольку тобой был использован чуть ли не самый популярный прием демагогии — доведение до абсурда, то с чистой совестью вешаю ярлык: вы сударь — демагог!
Развешивание ярлыков — еще более популярный прием демагогии.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Gajdalager, Вы писали:
G>>Т.о. .Нет 1.1 все-таки кросплатформенный за небольшим исключением. CC>Нельзя быть немного беременной. Или кроссплатформ или нет.
Кроссплатформенный в рамках стандарта ISO на CLR. Т.е. MSIL код запустится везде, а вот набор библиотек в Mono (пока?) не соответствует полностью MS.NET. Более подробно Mono Migration Analyzer, Results — Miguel de Icaza.
CC>Иначе получается кросс только для негуевых прог.
Пользуй Gtk# и будет тебе кроссплатформенный GUI. Да и реализация WinForms в Mono уже не так плоха — вон Paint.NET запустили под Linux:
При этом основная проблема была в том, что Paint.NET пользовался Windows-specific функциями:
This Paint application despite its young age is quite sophisticated and calls into a number of Win32 libraries to use features not exposed directly by the .NET libraries. For example, it determines the number of CPUs to adjust its thread pool, it uses low-level heap routines from the OS and other things like that.
Вопрос в библиотеках. Дело в том что значительная часть библиотек .NET не стандартизована, а выпущена чисто MS.
Но это с любым языком/платформой так. Ты же не можешь использовать С++/COM/MFC программу в Линукс. А C++/Qt можешь и в Windows и в Linux.
G>>Думаю, если бы МС вложила в развитие Моно (или даже своего собственного порта .Нета под Линукс) хотя бы половину денег, которые вложила в разработку платформы под винду CC>Ага щаззз...
Java давит своей кроссплатформенностью, поэтому все возможно.
G>>В плюсах же ВМ и ГЦ нет CC>И это является плюсом плюсов.
Где плюс, а где и минус. В бизнес-приложениях Java вытеснила C++ на задворки.
Здравствуйте, Plague, Вы писали:
P>Хех, как Вы хитро сюда к разговору Вирта прикрутили, это намек на Оберон? Его простота в отсутствии "Синтаксического оверхеда"?
Не простота (simplicity), а чистота (purity) — отсутствие всего наносного, излишнего.
Нельзя сказать что оберон-системы сложные, но и нельзя сказать что они простые, они просто чистые.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Plague, Вы писали:
P>>Хех, как Вы хитро сюда к разговору Вирта прикрутили, это намек на Оберон? Его простота в отсутствии "Синтаксического оверхеда"?
СГ>Не простота (simplicity), а чистота (purity) — отсутствие всего наносного, излишнего. СГ>Нельзя сказать что оберон-системы сложные, но и нельзя сказать что они простые, они просто чистые.
Ассемблер тоже туда запишем? Зачем нам что-то "наносное" к тому, как оно "внутрях" работает?
Здравствуйте, dmz, Вы писали:
dmz>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, dmz, Вы писали:
J>>>>Когда метапрограммирование начало использоваться промышленно?
J>>Ну, я не помню там особого метапрограммирования. Рефлексия — да, была.
dmz>Согласно источникам, там еще были метаклассы.
Насколько я помню, они ничего не умели. В основном их функция сводилось к созданию новых объектов классов. Но могу и ошибаться.
J>>И потом, ну какой это промышленный язык? Когда количество проектов на нем хотя бы приближалось к количеству J>ООП-проектов на других ООП-языках?
dmz>А какие еще в 80-х были ООП языки? И каково было вообще количество проектов? Есть подозрение, что dmz>сильно меньше, чем сейчас.
А причем тут сейчас? Вспомни, на какой тезис я отвечал. Короче, см. ответ Трурлю рядом
dmz>>>В принципе, кодогенерация это тоже, в некотором роде, метапрограммирование. А лет кодогенерации лет наверное немногим меньше, чем программированию.
J>>Метапрограммирование — это руление кодом программы из самого кода на этом же языке в той же самой программе. J>>А кодогенерация — это кодогенерация, у нее свое место.
dmz>С тобой согласны не все:
dmz>
Metaprogramming is the writing of programs that write or manipulate other programs (or themselves) as their data or that do part of the work that is otherwise done at runtime during compile time. This allows programmers to produce a larger amount of code and get more done in the same amount of time as they would take to write all the code manually.
dmz>Да и из практических соображений, велика ли разница — сам язык предоставляет средства манипулирования порождаемым кодом, или внешний тул? Вот взять С — препроцессор, там, конечно, часть языка — но больших проблемах написать препроцессоров на чем угодно и использовать их — нет. Какая разница при этом? Родной препроцессор в принципе, сильно отличается от языка в целом. То же можно и сказать о шаблонах — они, согласно стандарту, часть языка — но при этом сильно отличаются от остального языка. Это целая новая концепция, с другими выразительными средствами и даже подходом.
Я объясню, в чем разница.
Препроцессор был тыщу лет, еще в Си.
Шаблоны — не тыщу, но для чего они использовались (и для чего были созданы)? Правильно, для обобщенных контейнеров и функций типа min/max. И не были они никакой "новой концепцией, с другими выразительными средствами и даже подходом".
C тех пор ничего эпохального в С++ (в язык) привнесено не было, все, что мы имеем сейчас, все эти навороты — в общих чертах были реализуемы и раньше, в основном происходила чистка от граблей, которые мешают реализовывать вдруг открывшиеся возможности, о которых никто и не подозревал.
Скажем, метапрограммирование с использованием препроцессора (Boost.Preprocessor) было возможно еще в Си.
И что, кто-то озаботился этим? Нет. Только в последнее время. Или, ты думаешь, шаблоны сразу разрабатывались как полный по Тьюрингу язык времени компиляции? Естественно, нет. Так почему же _сейчас_ все бросились использовать шаблоны и препроцессор для вещей, на которые они изначально не были рассчитаны? Ответ простой: потому что _сейчас_ стало ясно, что без этого не жить.
В чем, собственно, и состоял мой тезис. Не была тогда поддержка метапрограммирования и рефлексии базовой вещью, необходимой в каждом универсальном языке программирования. Иначе всю эту магию препроцессора открыли бы еще в сишные времена.
J>>А какая разница? И там, и там метапрограммирование. J>>И Александреску совсем не был первым извращенцем, кстати
dmz>Ну разница где-то в том, что вычисление факториала числа в компайл-тайме dmz>практически бесполезно, несмотря на то, что реализовано при помощи "метапрограммирования".
Это просто proof of concept. Поскольку вычисления ведутся на уровне типов, то результатом обычно являюются тоже типы.
Факториал — это просто демонстрация для тех, кто в жизни функционального программирования не видел. Сглаживание кривой обучения, так сказать — факториал рекурсивно считать умеют все. Реальное же использование всего этого дела — Boost.MPL.
J>>По количеству часов, отводимых на него, и количеству программистов, выпускавшихся специалистами по метаязыкам — J>что ,столько же ,сколько по С/С++/VB?
dmz>По количеству часов, честно говоря, не знаю. Знаю только, что в MIT CS учили с чего-то вроде схемы, по пути реализовав ее интерпретатор в рамках курса. А VB в штатах учат таксистов, на недельных курсах.
Я тоже видел пост об этом, но у меня сложилось впечатление, что речь шла о нынешнем времени, а не о времени создания С++. Опять же, могу ошибаться.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Gajdalager, Вы писали:
G>>Т.о. .Нет 1.1 все-таки кросплатформенный за небольшим исключением. CC>Нельзя быть немного беременной. Или кроссплатформ или нет. Иначе получается кросс только для негуевых прог. здесь
G>>С другой стороны, в Жавы есть реальная кросплатформенность, с этим, думаю, не поспоришь. CC>В те древние времена когда я работал в жабовом проекте с кроссплатформенностью там были проблемы. И это на чисто бизнес проекте где ничего HW specific не было. Правда давно это было ...
Ну С++ тоже не сразу писался За время моей очень скромной карьеры я с проблемами запуска моего кода под определенную платформу не сталкивался G>>В плюсах же ВМ и ГЦ нет CC>И это является плюсом плюсов.
Не знаю, мне пока ни то, ни другое совсем не мешало G>>На засыпочку. Сколько времени тебе нужно убить, чтобы скомпилировать и запустить код, отлично портируемый между Win-32 и Linux, на 64-битную архитектуру? CC>Чью 64 битную? Win/Lin?
А все равно.. Лучше бы, конечно и туда, и туда, поскольку жава и там и там: http://java.sun.com/javase/6/webnotes/install/system-configurations.html
.Net кстати тоже есть и под Win-32 и под Win-64.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Кроссплатформенный в рамках стандарта ISO на CLR. Т.е. MSIL код запустится везде, а вот набор библиотек в Mono (пока?) не соответствует полностью MS.NET.
Подытоживая: в более общем случае почти любая VM-based прога будет кроссплатформенной. И будет работать на любой платформе где под нее напишут VM. А если еще и JIT прикрутят то вапще гут.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Кроссплатформенный в рамках стандарта ISO на CLR. Т.е. MSIL код запустится везде, а вот набор библиотек в Mono (пока?) не соответствует полностью MS.NET. CC>Подытоживая: в более общем случае почти любая VM-based прога будет кроссплатформенной. И будет работать на любой платформе где под нее напишут VM. А если еще и JIT прикрутят то вапще гут.
Угу
Здравствуйте, Курилка, Вы писали:
К>Ассемблер тоже туда запишем? Зачем нам что-то "наносное" к тому, как оно "внутрях" работает?
Да! Вот именно! Но далеко не любой. Иные наборы машинных команд (к каковым относится и набор команд x86) при всём желании невозможно назвать чистыми. Придумать хороший набор команд не просто.
По сути язык Оберон и есть "ассемблер", только объектно-ориентированный и для "оберон-машины".
СГ>Не простота (simplicity), а чистота (purity) — отсутствие всего наносного, излишнего. СГ>Нельзя сказать что оберон-системы сложные, но и нельзя сказать что они простые, они просто чистые.
Здравствуйте, FR, Вы писали:
K>>Возмножно, но весьма сложно. В принципе, можно браться за любой сложности задачу, однако, когда сложность превышает все возможные пределы, можно сказать, что решить задачу невозможно (на самом деле, экономически невыгодно).
FR>В чем сложность то? Мне кажется ты сильно преувеличиваешь то упрощение которое дают для данного класса задач ML подобные языки. Если бы ты был прав, то компиляторя уже очень давно писались бы только на чем то ML подобном например на Ocaml.
Да, на ML-подобных языках компиляторы писать удобнее. Однако тут уж вступают в игру иные факторы. Например, сложность изучения ML. Чтобы на C++ писать, Вася Пупкин может прочитать книжку "C++ для идиота" и чего-нибудь да напишет (правда ему за такую писанину руки надо будет отрубить). Для того, чтобы тот же Вася выучил ML, нужно чтобы он имел некоторые фундаментальные знания и опыт. Отсюда следует непопулярность ML. А именно популярность (но никак не удобство), к сожалению, определяет, на чём пишется софт. Ну можно ещё привести аргументы. Например, есть GNU-ортодоксы, которые до сих пор предпочитают C с синтаксисом K&R для тех приложений, для которых он не очень подходит (например GUI).
Здравствуйте, Cyberax, Вы писали:
C>Напишешь Quake4 на Питоне?
Нафига? Вон, Цивилизация 4 на питоне фактически написана, только движок на C++. А в кваке нет ничего такого, что требовало бы четырёхэтажных скриптов. Фактически, почти вся игра состоит из одного движка. Движки действительно писать можно только на C++, а жаль . Может быть, в будущем что-то изменится.
Здравствуйте, konsoletyper, Вы писали:
K>Движки действительно писать можно только на C++, а жаль .
Извините за переход на личность, но у вас уже не в первый раз проскальзывает просто таки жуткое неприятие C++.
Но, как я понял, проекты в миллионы строк в компании с низкоквалифицированными программистами на C++ вам вести не приходилось. Так откуда же такая нелюбовь ожесточенная? Что же в нем такого отталкивающего?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
AndreiF wrote: > CC>На любом другом кстати тоже... > Это уже отельный вопрос. А факт — это то, что универсальность плюсов > сильно преувеличивают. И никакого Q4 "на чистом С++" никто не напишет.
Я вот заявляю, что Оффис без VB в принципе не написать. Иначе как на нем
макросы писать?
Сергей Губанов wrote: > Да! Вот именно! Но далеко не любой. Иные наборы машинных команд (к > каковым относится и набор команд x86) при всём желании невозможно > назвать чистыми. Придумать хороший набор команд не просто.
MIPS32 — очень чисто и красиво.
konsoletyper wrote: > C>Напишешь Quake4 на Питоне? > Нафига? Вон, Цивилизация 4 на питоне фактически написана, только движок > на C++.
Поэтому CivIV всеми и считается жутко тормозящей
> А в кваке нет ничего такого, что требовало бы четырёхэтажных > скриптов. Фактически, почти вся игра состоит из одного движка. Движки > действительно писать можно только на C++, а жаль . Может быть, в будущем > что-то изменится.
А зачем?
Здравствуйте, Lloyd, Вы писали:
L>А как же пачка багов, которые nikov обнаружил в компиляторе только-только начав с ним работать?
Он такие пачки где угодно находит. Компиляторы МС и РеШарпер не исключение.
L>Страшно подумать, что выплыло бы, если бы он попытался использовать его в продакшн-е.
На самом деле ничего страшного. Большинство найденных багов экзотика с которой в жизни не сталкнешся. Да и не вызвают они особых проблем. Максимум пришлось бы на форум за консультацией обратиться. Вот проблемы с Юникомдом еслине порешить, то проблем будет намного больше.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Я бы хотел услышать ответ из первоисточника. E>Поскольку твое мнение, по крайней мере на моем опыте, не имеет ничего общего с действительностью.
Слушай. Только вот похоже его не интересуют ответы тем кто не хочет уважать чужое мнение.
E>Весь стандарт в подавляющем большинстве случаев и не нужен. E>Не всегда даже нужна поддержка специализаций шаблонов, не говоря уже о частичной специализации.
Да, да. Вот разумные люди и ограничивают набор С++ фич до фич С. Далее следует разумный вывод о том, что использование за одно и С-компилятора даст им бльшую переносимость с меньшим геморроем. И я их понимаю. Уж если ограничивать себя ради совместимости, то делать это полседовательно.
E>Сколько некачественных C++ компиляторов, когда и на каких платформах тебе доводилось видеть или использовать. И сколько в это же время и на этих же платформах было компиляторов с отличных от C/C++ языков?
Я не видел ни одного качественого компилятора С++ вообще. Слышал про один, но в руках не деражал. В прочем, это не мешало мне писать код для Win32 на VC 1.5, 5, 6, 2002, 2003, а так же Ваткоме и Борланде. Конечно же о переносимости и речи не шало.
В то же время переносимых компиляторов других языков выше крыши. Одних Лиспов за это время наклепано шутк 20. А уж если считать разные Обероны и Фир Паскли, то их число наверно дойдет то сотен. И большинство из них намного более полно соблюдают стандарты языков.
VD>>Сложно потому что много UB.
E>Это к портируемости вообще имеет косвенное отношение.
Еще как имеет. Если ты допустил UB в программе (скорее всего не явно), то на одной платформе все может работать, на другой валиться с неясными причинами. А иной раз даже валиться на ровном месте без обявления войны после долгих лет безупречной работы.
VD>>Сложно потому, что язык в угоду оптимизации создает массу сложностей вроде платформно-зависимых типов...
E>Платформенно-зависимые типы не являются проблемой даже если требуется организовывать обмен данными между различными платформами.
Явяютя. И не признавать это можно только от очень большой предвзятости.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jazzer, Вы писали:
J>Ты не согласен? Старая? И когда же метапрограммирование начало рассматриваться и применяться как полноценный метод программирования наряду с другими? До рождения С++?
Ага. За долго. Где-то в 50-тых.
J>Только не надо говорить, что метапрограммирование появилось, как только появился первый интерпретатор с командой eval (вообще говоря, тут и eval не нужен — ты можешь просто сгенерить из своего скрипта рядом файл с новым кодом и позвать его — чем не метапрограммирование).
Конечно не надо. Оно появилось за долго до этого. Первые компьютеры программировались в маш.кодах и тогда метапрограммирование очень сильно выручало.
Далее для облегчения создания компиляторов был придуман BNF и так называемые компиляторы компиляторов. Первый из них появлися где-то в 1960-1965-ом (Atlas Autocode).
С++ же появился в 1985-ом. Чувствуешь разницу? И кстати, причем тут С++. Макросы были еще в С, а метапрограммирование на шаблонах появилось вообще где-то во второй половине 90-ых.
ЗЫ
Ейбогу С++ — это вра. Более того — это отдельный мир. Для тех кто в нем живет ничего кроме него вокруг не существует.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jazzer, Вы писали:
J>Ну и макросы макроассемблера тоже
А как же?
J>давайте все же разделим, что мы считаем метапрограммированием, а что — нет.
Давай. Мое определение очень точно — это написание программы которая порождает другую программу.
Ты удивишся, но макросы в С — это чистешей воды метапрограммирование. Причем иной раз более эффективное чем последняя версия шаблонов С++. Вот только создающая много проблем и имеющая тучу недостатков.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jazzer, Вы писали:
J>Шаблоны в С++ тоже вон были давно, но применяться для метапрограммирования и программирования в функциональном стиле они стали совсем недавно,
Шаблоны то конечно были. Правда не очено давно (меньше чем существует С++), но вот одна загвоздка. Для их применения в целях метапрограммирвоания не просто шаблоны, а шаблоны допускающие рекурсивное определение, а это появилось в реальных компиляторах только где-то в конце 90-ых прошлого века. Даже VC 6 выпуска 1998 года имел кучу проблем в этой области и реально применяться для этого не мог. Следующая версия VC вышла в 2002 году.
Меж тем макросам С столько же лет как и самому С. И это далеко не первый случай применения специальных мета-языков.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jazzer, Вы писали:
J>Так почему же _сейчас_ все бросились использовать шаблоны и препроцессор для вещей, на которые они изначально не были рассчитаны? Ответ простой: потому что _сейчас_ стало ясно, что без этого не жить.
Это твой взгляд на мир из твоего мира (в котором кроме С++ ничего не видно).
Но есть и другие взгляды.
Есть люди которые занимались метапрограммированием на препроцессоре С еще когда и С++ небыло. Кстати, ты будешь подавлен, но Страуструп во всю занимался метапрограммированием на макросах С. Достоверно известно, что первая реализация шаблонов была реализована на препроцессоре С. Не хило правда?
Еще были люди которые писали внешние метапрограммы, которые ты называешь кодогенераторами.
Еще были те кто использовал тот же Лисп.
Еще были те кто использовал метапрограммирование в динамических языках типа Питона. В нем метапрограммирование тоже появилось до того как Шаблоны С++ стали позволять рекурсивные вычисления.
В общем, метапрограммирование появилось практически параллельно самому программированию и все это время совершенствовалось и развивалось. Есть разные подходы к метапрограммированию. И надо признать, что подход С++ многие считают как раз неверным. И я в том числе.
Если уж мы хотим иметь встроенные в язык средства метапрограммировани, то разумно было бы хотеть так же, чтобы метапрограммы писались на том же языке, что и обычные. В Лиспе — это так. В Немерле — это так. А вот в С++ — это не так. В нем как бы был нйден новый куций функциональный язык реализованный как побочный эффект от рекурсивного определения шаблонов. И это совсем не тот же язык что С++. Плюс к тому же он интерпретируемый и очень ограниченный как в выразительном плане, так и в функциональном. Попробуй, например, с его помощью прочитать что-то из внешнего файла.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
CC>Все зависит от квалификации человека. Плохой и нечитабельный код можно написать практически на любом более менее серьезном ЯП
Несомненно! Язык — это только усилитель тех или иных свойсвт. И С++ удивительно гормонично сочетает в себе возможности по усилению ошибок и сложности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Так BrainFuck очень простой язык.
Тогда определитесь с терминалогией. Простой язык — это язык на котром просто писать? Который имеет простой синтаксис? Который имеет простую семантику? Который имеет простые синтаксис и семантику? Который логичен, интуитивно понятен и безопасен?
Все это разные вещи. И все это можно понимать под простатой.
Брэйнфак прост синтаксически и семантически, но не интуитивен и не понятен.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
CC>Нельзя быть немного беременной. Или кроссплатформ или нет. Иначе получается кросс только для негуевых прог.
Значит С++ не кросплатформный? У него в стандарте тоже нет переносимого ГУИ.
А в Моно есть поддержка GTK. И сборки написанные для него переносимы туда где есть GTK.
Вообще это бред про Моно уже достал.
Ребяты (с) Моно прекрасно переносим. Есть только две беды. Первая — моно значительно уступает дотнету в некоторых аспектах. Так он медленее, имеет больше багов, имеет меньше библиотек (например, того же WPF).
Однако это никак не мешает переносимости программ если они изначально создавались в рассчете на запуск под Моно.
Вторая — многим тем кто выбирает технологии МС просто начхать и растереть на все что делается пол Уних в общем, и под Линукс в частности.
Собственно точно так же дела обстоят и с С++. С++ от МС отличается от стандарта С++ и от других его реализаций. И если писать программы только в рассчете на С++, то непереносимая прграмма получается сама сабой в автоматическом режиме.
Собственно и с качеством дела обстаят точно так же. Даже тот же GCC во многом уступает VC или IntelC++. И там где нет этих компиляторов вы точно так же получите боьше проблем и более низкую скорость кода.
Так что это общие проблемы переносимости. Но у С++ этих проблем тем не менее больше. И сам процесс поддержания прогаммы способной одинаково хорошо работать на разных платфомах сложнее. Ведь VM, хорошо спроектированный язык и библиотеки — это оличный слой абстракции. А С++ так бездарно спроектирован и имеет такой зоопарк в ибилиотеках, что всю абстракцию в нем надо выписывать самому. В общем, если вы любите боль, то С++ — это ваш выбор. Безусловно на нем можно создавать хорошие, быстрые и надежные программы. Вопрос только какой ценой и с каким удовольствием от процесса.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Для C/C++, в принципе, можно кроме объектных файлов для каждого исходника еще какой-то прекомпилированный файл строить -- объемы винчестеров и их сейчас это позволяют.
Так все современные компиляторы и поступают. Получаетя для мегабайтных (по побъему исходников) проектов генерируются гигабайты грязи. Жаль только что компиляцию это не сильно ускоряеет... по сравнению с модульными языками.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Извините за переход на личность,
Да ничего страшного.
E>но у вас уже не в первый раз проскальзывает просто таки жуткое неприятие C++.
Есть немного. Только насчёт жуткого — преувеличение.
E>Но, как я понял, проекты в миллионы строк в компании с низкоквалифицированными программистами на C++ вам вести не приходилось. Так откуда же такая нелюбовь ожесточенная? Что же в нем такого отталкивающего?
ИМХО, язык жутковатый. Я уже приводил здесь конструкцию, необходимую для обеспечения модульности (чтобы один и тот же файл не инклюдился два раза). Есть много маленьких мелочей. Например, почему я должен к статическому члену класса обращаться через "::", а не через "."? Зачем дважды дублировать сигнатуру метода в .h и .cpp файлах? Почему чтобы сделать вложенный неймспейс, я не могу использовать точечную нотацию, а должен вкладывать друг в друга несколько блоков? Почему существуют три различных способа приведения типа? Почему метапрограммные навороты выглядят так жутко? Почему нет нормального способа прикрутить человеческий GC, свойства, события и т.д. Наконец, почему, чтобы понять C++, нужно от и до внимательно прочитать Страуструпа, а потом ещё Липпмана?
Впрочем, на все эти вопросы я и сам могу дать ответ. Я так же могу дать ответ на подобные "почему" касательно PHP. Но вот беда: есть языки, к которым подобных вопросов не задаётся.
Здравствуйте, Cyberax, Вы писали:
C>konsoletyper wrote: >> C>Напишешь Quake4 на Питоне? >> Нафига? Вон, Цивилизация 4 на питоне фактически написана, только движок >> на C++. C>Поэтому CivIV всеми и считается жутко тормозящей
Это кем? Вот мой текущий комп практически не апгрейдился с 2003 года, видюха вообще никакая, так играется вполне сносно (только на огромной карте где-то к XX веку начинается жуткий своп, и FPS низкий, на моей видюхе он где угодно низкий). А вот мой батя на новый год купил себе новый комп, причём далеко не самый лучший. Что-то я от него жалоб не слышал.
А вот если бы Civ 4 написали на .NET, то и на моём компе проблем никаких не было бы.
>> А в кваке нет ничего такого, что требовало бы четырёхэтажных >> скриптов. Фактически, почти вся игра состоит из одного движка. Движки >> действительно писать можно только на C++, а жаль . Может быть, в будущем >> что-то изменится. C>А зачем?
Затем, что в будущем игры должны становиться красивее, эффектнее, реалистичнее. Для этого нужен будет мощный движок. Вот тогда мы все и поймём, зачем.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, konsoletyper, Вы писали:
K>>Движки действительно писать можно только на C++, а жаль . АХ>Да ладно тебе, можно и на C, С#, Pascal, Java...
На C#/Java пока не время. Экспериментировал с C# + ManagedDX. Пока слабовато, для серьёзных игр не потянет. А Pascal он же слабее C++.
Здравствуйте, Cyberax, Вы писали:
C>А ты напишешь ВЕСЬ Q4 на Питоне? Ведь оптимизация — это не задача.
Что про Питон то речь вести. Ясно, что писать движек на интерпретаторе неразумно дорого. Впрочем как и прикладную логику на С++.
Но какие ты видишь проблемы чтобы написать игру скажем на Немерле. Причем как скрипты, так и львиную долю движка? Ну, скажем если использовать XNA или хотя бы Menaged DX?
Учитывая, что при этом будут покрыты две огромные платформы — Windows и XBox 360, и то что Немерле даст фору обоим упомянутым языкам на их родном поле, то эта идея очень заманчива. Не находишь?
Причем время идет. Прогресс тоже. И скоро будет какй-нить XBox Wow 1024K в котором будет гиг оперативки 40 процессоров и другая круть. К тому времени XNA заматереет и облипнет тучей утилит и библиотек. Основной заботой будет сложность и масштабируемость, а вовсе не выжымание последних битов из последнего байта.
Что думаешь? А?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
konsoletyper wrote: > На C#/Java пока не время. Экспериментировал с C# + ManagedDX. Пока > слабовато, для серьёзных игр не потянет. А Pascal он же слабее C++.
C# в некоторых местах тоже, или нет? Pascal зато читаем человеком. С
приделанной кодогенерацией — можно жить...
Здравствуйте, Plague, Вы писали:
P>Хех, как Вы хитро сюда к разговору Вирта прикрутили, это намек на Оберон? Его простота в отсутствии "Синтаксического оверхеда"?
не нужно.
Впрочем, это, наверное, так интересно...
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
VladD2 wrote: > C>А ты напишешь ВЕСЬ Q4 на Питоне? Ведь оптимизация — это не задача. > Что про Питон то речь вести. Ясно, что писать движек на интерпретаторе > неразумно дорого. Впрочем как и прикладную логику на С++.
Просто был выдвинут тезис о том, что оптимизация — это не задача. Я
оспариваю именно этот тезис.
> Но какие ты видишь проблемы чтобы написать игру скажем на Немерле. > Причем как скрипты, так и львиную долю движка? Ну, скажем если > использовать XNA или хотя бы Menaged DX?
Медленнее будет, причем заметно. У меня знакомый товарищ, занимающийся
разработкой игр, уже пробовал XNA Studio — пишется неплохо, но вот
заметно торррмознее.
Так что для этого поколения консолей и PC пока managed в сложных играх
использоваться не будет. В следующих поколениях — возможно, но еще не в
этом. В общем, в 2010 посмотрим.
> Причем время идет. Прогресс тоже. И скоро будет какй-нить XBox Wow 1024K > в котором будет гиг оперативки 40 процессоров и другая круть. К тому > времени XNA заматереет и облипнет тучей утилит и библиотек. Основной > заботой будет сложность и масштабируемость, а вовсе не выжымание > последних битов из последнего байта. > Что думаешь? А?
Ну тут и альтернативные технологии подтягиваются. Мне вот лично нравится
LLVM — на ней можно было бы нормально (а не как в Managed C++)
совместить С++ и управляемые языки.
Подходы .NET и Java к созданию VM мне кажутся тупиком. Гибкости мало.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
J>>Ну и макросы макроассемблера тоже
VD>А как же?
J>>давайте все же разделим, что мы считаем метапрограммированием, а что — нет.
VD>Давай. Мое определение очень точно — это написание программы которая порождает другую программу.
VD>Ты удивишся, но макросы в С — это чистешей воды метапрограммирование. Причем иной раз более эффективное чем последняя версия шаблонов С++. Вот только создающая много проблем и имеющая тучу недостатков.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
J>>Так почему же _сейчас_ все бросились использовать шаблоны и препроцессор для вещей, на которые они изначально не были рассчитаны? Ответ простой: потому что _сейчас_ стало ясно, что без этого не жить.
VD>Это твой взгляд на мир из твоего мира (в котором кроме С++ ничего не видно).
-1. Переход на личность.
Остальное поскипано как не противоречащее моим высказываниям.
VD>Если уж мы хотим иметь встроенные в язык средства метапрограммировани, то разумно было бы хотеть так же, чтобы метапрограммы писались на том же языке, что и обычные. В Лиспе — это так. В Немерле — это так. А вот в С++ — это не так. В нем как бы был нйден новый куций функциональный язык реализованный как побочный эффект от рекурсивного определения шаблонов. И это совсем не тот же язык что С++. Плюс к тому же он интерпретируемый и очень ограниченный как в выразительном плане, так и в функциональном. Попробуй, например, с его помощью прочитать что-то из внешнего файла.
Все так, и это — недостаток С++, и я никогда не говорил обратного, да и никто (условно, если не брать в расчет фанатов) такого не говорит — всем известно, что метапрограммирование на шаблонах С++ открыли случайно и они не были под это заточены, и никто не говорит, что они жутко удобны или что они все могут.
Именно поэтому комитет по стандартизации с большим вниманием смотрит на все, что происходит в области метапрограммирования (см. цитату с их сайта). Потому что всем хочется иметь нормальные средства поддержки метапрограммирования в рамках самого языка.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
J>>Шаблоны в С++ тоже вон были давно, но применяться для метапрограммирования и программирования в функциональном стиле они стали совсем недавно,
VD>Шаблоны то конечно были. Правда не очено давно (меньше чем существует С++), но вот одна загвоздка. Для их применения в целях метапрограммирвоания не просто шаблоны, а шаблоны допускающие рекурсивное определение, а это появилось в реальных компиляторах только где-то в конце 90-ых прошлого века. Даже VC 6 выпуска 1998 года имел кучу проблем в этой области и реально применяться для этого не мог. Следующая версия VC вышла в 2002 году.
VD>Меж тем макросам С столько же лет как и самому С. И это далеко не первый случай применения специальных мета-языков.
Опять не пойму, с чем ты споришь. Ты меня хочешь в какой-то флейм втянуть, что ли?
Здравствуйте, konsoletyper, Вы писали:
K>>>Движки действительно писать можно только на C++, а жаль . АХ>>Да ладно тебе, можно и на C, С#, Pascal, Java...
K>На C#/Java пока не время. Экспериментировал с C# + ManagedDX. Пока слабовато, для серьёзных игр не потянет.
Хм, MS так не думает: Microsoft XNA. Там спецверсию компактного фреймворка замутили которая и на XBox 360 идет.
K> А Pascal он же слабее C++.
Ну слабее, я вообще эти Паскали-Обероны не люблю, но код там достаточно быстр, так что писать то можно.
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Plague, Вы писали:
P>>Хех, как Вы хитро сюда к разговору Вирта прикрутили, это намек на Оберон? Его простота в отсутствии "Синтаксического оверхеда"?
AVC>Просто там вот это AVC>http://www.rsdn.ru/Forum/Message.aspx?mid=707886&only=1
AVC>не нужно. AVC>Впрочем, это, наверное, так интересно...
Демагогия чистой воды.
В указанном посте описывается чистейшей воды извращение (цитаты: "Что-то вчера взбрело в голову", "заплатка для дебага"), а ты его сюда выносишь как будто все программы на С++ так пишутся.
Здравствуйте, eao197, Вы писали:
J>>В то время рулили всякие алголы и фортраны и прочие PL/1
E>Понятие "рулили" очень абстрактное. То, что большинство программистов в то время выполняли свою работу не на Lisp-е вовсе не означает, что на лиспе вообще не делалось важных и ответственных проектов. Думаю, что таки делались и метапрограммирование при этом использовалось на полную катушку.
Тогда понятие "бронзовый век" тоже очень абстрактное
Потому что наверняка кто-нть где-ть открыл возможность работы с железом.
И на этом основании давайте заклеймим все остальные кузни того времени как не имеющие "базовой вещи" — печи для работы с железом.
С++ вполне соответствовал состоянию индустрии на момент его создания.
Тогда позарез нужен был язык с ООП.
Это сейчас все во всех областях приложения программирования рванули в сторону функциональных языков и метапрограммирования. Ничего подобного, я уверен, в то время не было. Конечно, были отдельные проекты, и вообще разных языков было за сотню, наверное.
Но не было такого, чтобы, образно говоря, программисты стояли на улицах с плакатами: "Дайте нам язык с поддержкой рефлексии и метапрограммирования, без него не жить". А было "Дайте нам язык с поддержкой ООП, но чтоб он не тормозил, как Смолтолк, а работал со скоростью Си".
Скажем (может, сейчас Сергей Губанов подтянется), почему следующая версия Паскаля называлась Object Pascal, а не Meta Pascal?
Раз, как вы утверждаете, был большой запрос на это дело со стороны индустрии и это считалось "базовой вещью"?
Неужели я так криво пишу, что меня вообще невозможно понять?
Здравствуйте, Kisloid, Вы писали:
K>Здравствуйте, jazzer, Вы писали:
J>>Ты не согласен? Старая? И когда же метапрограммирование начало рассматриваться и применяться как полноценный метод программирования наряду с другими? До рождения С++?
K>
K>Впервые термин квази-цитирование был введен известным специалистом в области логики Уиллардом Куини в 1940 году. Куин использовал квази-цитирование для конструирования выражений математической логики. И первым языком, использующим, механизм квази-цитирования стал Lisp разработанный Джоном Маккарти примерно в 1960 году, но внедрен в язык и начал применяться только с середины 70-х годов.
K>(с) мой, отрывок из моей работы
Спасибо за экскурс , но что, разве все программисты после этого сразу сказали: "Вау, как это круто, эй, если кто тут соберется разрабатывать новый язык — имейте в виду, если в нем не будет такой базовой вещи как квази-цитирование, он нафиг никому не будет нужен"?
АХ>Ну если многие использовали (и используют) VC++ 6.0 который абсолютно не соответствует стандарту C++, имеет реализацию STL, в которой течет память, и частенько ICEится, то чему удивляться.
offtop.
Нельзя ли немного подробнее о проблемах с STL? Немного тут отстал от жизни...
Здравствуйте, konsoletyper, Вы писали:
K>Например, почему я должен к статическому члену класса обращаться через "::", а не через "."?
Обращайся через точку, на здоровье Попробуй сначала
K>Зачем дважды дублировать сигнатуру метода в .h и .cpp файлах?
Ну не дважды Одного дублирования вполне достаточно
Потому что в языке есть перегрузка, и компилятору банально нужно откуда-то догадаться, что ты имеешь в виду, определяя функцию f — f(int) или f(double, string). Плюс совместимость с Си?, в которой перегрузки не было, а было хрен знает что вообще без сигнатур. Не хочешь дублировать — пиши в стиле Java, объявляя все в заголовочных файлах.
K>Почему чтобы сделать вложенный неймспейс, я не могу использовать точечную нотацию, а должен вкладывать друг в друга несколько блоков?
Боремся с синтаксическим оверхедом?
K>Почему существуют три различных способа приведения типа?
Исторически (например, совместимость с Си). Они тебе чем-то мешают? Выбери один, которй тебе по душе, и пользуй его — в чем проблема?
K>Почему метапрограммные навороты выглядят так жутко? Почему нет нормального способа прикрутить человеческий GC, свойства, события и т.д. Потому что язык не был на все это рассчитан. Не было в его списке design goals соответствующих пунктов (а вот совместимость с Си была).
А сейчас есть — смотри ссылку в исходном топике.
Времена меняются — меняются и требования.
Успеет С++ измениться, чтоб соответствовать современным требованиям — будет жить.
Не успеет — останется только в legacy-проектах.
K>Впрочем, на все эти вопросы я и сам могу дать ответ. Я так же могу дать ответ на подобные "почему" касательно PHP. Но вот беда: есть языки, к которым подобных вопросов не задаётся.
С этим тоже никто не спорит. К ним задаются другие вопросы (например, почему в Java нет const?)
Здравствуйте, Cyberax, Вы писали:
C>Я вот заявляю, что Оффис без VB в принципе не написать. Иначе как на нем C>макросы писать?
Ну во первых, не VB, а VBA — это очень разные вещи.
Во вторых, интерпретатор VBA — это одна из составных частей офиса, написанная тем же производителем что и офис.
Здравствуйте, IT, Вы писали:
R>>Ну а как насчёт, ну не знаю, доступа к регистрам аппаратуры, или "написания программы на машинном коде" (ну это когда ты пишешь программу на яву, но при этом фактически знаешь, что будет делать процессор).
IT>Попробуй записать на C++ что-нибудь в порт под виндой, а я посмотрю
Запускаю драйвер GiveIO.sys и пишу (inp, outp). Более того, мы даже на C++/CLI это делали
AndreiF wrote: > C>Я вот заявляю, что Оффис без VB в принципе не написать. Иначе как на нем > C>макросы писать? > Ну во первых, не VB, а VBA — это очень разные вещи.
Мне это можно не говорить, я в свой проект встраивал VBA из VBA SDK.
> Во вторых, интерпретатор VBA — это одна из составных частей офиса, > написанная тем же производителем что и офис.
Ты утверждаешь, что оффис невозможен без VBA в принципе?
> Так что ты доказать то хотел?
Это я про невозможность Q4 без скриптов.
Здравствуйте, Nuald, Вы писали:
IT>>Попробуй записать на C++ что-нибудь в порт под виндой, а я посмотрю
N>Запускаю драйвер GiveIO.sys и пишу (inp, outp). Более того, мы даже на C++/CLI это делали
Вот! Что и требовалось доказать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Вот! Что и требовалось доказать.
Не знаю, что требовалось доказать, но по идее и на дотнетовском языке можно работать с низкоуровневыми вещами. Например, вот так рефлектор показывает наш метод, пишущий в порт:
internal static unsafe int modopt(CallConvThiscall) InteropHelper.UnmanagedHardwareAccessor.InPort(UnmanagedHardwareAccessor* modopt(IsConst) modopt(IsConst), ushort portAddress)
{
int num1 = _inp(portAddress);
return (int modopt(CallConvThiscall)) num1;
}
А inp декларируется как:
[MethodImpl(MethodImplOptions.Unmanaged, MethodCodeType=MethodCodeType.Native), SuppressUnmanagedCodeSecurity, DllImport("", EntryPoint="", CallingConvention=CallingConvention.Cdecl, SetLastError=true)]
public static extern int modopt(CallConvCdecl) _inp(ushort);
P.S. Не хочу, чтобы это воспринималось как защита дотнета, у меня после нескольких лет работы с ним он не вызывает других эмоций, кроме отрицательных, впрочем как и другие поделки от мелкомягких типа MFC и ATL, но выбора особого нет, серебряной пули нет
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, jazzer, Вы писали:
J>>С++ вполне соответствовал состоянию индустрии на момент его создания. J>>Тогда позарез нужен был язык с ООП.
K>А чем не устроила, скажем, ADA? Она к моменту выхода обладала интересными фичами, например, generics. Ну уж точно мощнее C++ образца 80-х.
Ada 95 added support for object-oriented programming, including dynamic dispatch.
С++ был объектно-ориентированным с самого начала,
а в 95-м году в нем уже было практически все, что мы имеем в нем сейчас (у меня издание ARM как раз 95-го года и там есть тогдашние ANSI/ISO resolutions с новыми кастами, пространствами имен и т.п.) и язык двигался полным ходом к стандартизации, которая произошла в 98-м, включив в С++ STL (кстати, если кто не знает, STL изначально разрабатывалась для Ады, причем начал он работать над STL, когда С++ еще и в помине не существовало).
Здравствуйте, Андрей Хропов, Вы писали:
АХ>И некоторые уже так и делают — вот например в небезызвестной игре Second Life для скриптов потихоньку пытаются встроить рантайм Mono:здесь.
Кстати говоря, беглая проверка показала наличие dotnetfx.exe в дистрибутивах целого ряда новых игр — Titan Quest, Half-Life 2 Episode One, Flatout 2. Неясно правда, в каких объемах там используется .NET.
Здравствуйте, VladD2, Вы писали:
VD>Несомненно! Язык — это только усилитель тех или иных свойсвт. И С++ удивительно гормонично сочетает в себе возможности по усилению ошибок и сложности.
И усилению самомнения программиста, который продравшись через горы проблем и заморочек, добирается наконец до решения задачи
Никакой другой язык не дает такого удовлетворения — там слишком просто всё делается
AndreiF wrote: > C>Мне это можно не говорить, я в свой проект встраивал VBA из VBA SDK. > Тогда удивительно, что ты их путаешь.
Не путаю. Просто привык называет его просто VB.
> C>Ты утверждаешь, что оффис невозможен без VBA в принципе? > Скрипты в офисе — для пользователя, а не для программистов офиса. А > скрипты в играх — для программистов игр.
В Doom скриптов, например, не было. И что?
Вообще, в тех же Q1/2/3 скрипты — это просто входные данные, как и
шейдеры или текстуры.
AndreiF wrote: > Кстати говоря, беглая проверка показала наличие dotnetfx.exe в > дистрибутивах целого ряда новых игр — Titan Quest, Half-Life 2 Episode > One, Flatout 2. Неясно правда, в каких объемах там используется .NET.
Скорее всего, для сопутствующих утиллит. Так как тот же HL2 будет
портирован на PS3.
Depends не показавает зависимостей в HL2E1 от .NET, во время работы игры
— тоже не обнаружено.
Здравствуйте, jazzer, Вы писали:
J>Скажем (может, сейчас Сергей Губанов подтянется), почему следующая версия Паскаля называлась Object Pascal, а не Meta Pascal?
Я не Сергей, но вообще-то следующая версия паскаля называлась Modula.
Здравствуйте, VladD2, Вы писали:
VD>Значит С++ не кросплатформный? У него в стандарте тоже нет переносимого ГУИ.
Пардон, WinForms входит в комплект библ .NET. По сути является стандартной библиотекой. В С++ в стандартной библиотеке этого нет. Стандартные библиотеки должны быть переносимы, в противном случае это не кроссплатформенность а геморрой с бантиком. Так что претензия ИМХО мимо кассы...
VD>А в Моно есть поддержка GTK.
GTK есть в стандартных библиотеках .NET? Нету? Тогда мимо кассы...
VD>Ребяты (с) Моно прекрасно переносим. Есть только две беды. Первая — моно значительно уступает дотнету в некоторых аспектах. Так он медленее, имеет больше багов, имеет меньше библиотек (например, того же WPF). VD>Однако это никак не мешает переносимости программ если они изначально создавались в рассчете на запуск под Моно.
Стоп! Вот отсюда помедленнее: моно все таки это .NET под никсы или это что то отдельное, но бинарно совместимое? Если отдельное то при чем тут вообще Моно к портируемости .NET? То, что моно переносим — отдельная песТня. Речь изначально шла исключительно про кроссплатформенность .NET
VD>Вторая — многим тем кто выбирает технологии МС просто начхать и растереть на все что делается пол Уних в общем, и под Линукс в частности.
Т.е. все утверждения что гипотетическая кроссплатформенность .NET это ее бааальшой плюс можно сразу отправлять в void, уже по причине полной ненужности этой самой кроссплатформенности.
VD>Собственно точно так же дела обстоят и с С++. С++ от МС отличается от стандарта С++ и от других его реализаций. И если писать программы только в рассчете на С++, то непереносимая прграмма получается сама сабой в автоматическом режиме.
Более правильным было бы сказать "только в рассчете на один из компиляторов С++, то непереносимая прграмма получается сама сабой в автоматическом режиме".
Реализация VM для дотнета только одна. Компилеров С++ же много, они бинарно несовместимы в большинстве своем. Пиши под один GCC на все нужные тебе платформы и будет тебе щасте!
VD>И сам процесс поддержания прогаммы способной одинаково хорошо работать на разных платфомах сложнее.
Гм. x86, PS2, XBOX — наше двигло вроде нормально на них работало, Один код, только разделение по hardware dependent уровню и все.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Так BrainFuck очень простой язык.
VD>Тогда определитесь с терминалогией. Простой язык — это язык на котром просто писать? Который имеет простой синтаксис? Который имеет простую семантику? Который имеет простые синтаксис и семантику? Который логичен, интуитивно понятен и безопасен?
VD>Все это разные вещи. И все это можно понимать под простатой. VD>Брэйнфак прост синтаксически и семантически, но не интуитивен и не понятен.
BrainFuck имеет простой синтаксис, простую семантику, логичен, интуитивно понятен и безопасен, но на нем почти невозможно писать так как он слишком низкоуровневый язык.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Хм, MS так не думает.
Открою тебе страшную тайну: микрософт думает только о том, как продать свои творения и подсадить на них еще больше народу.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, jazzer, Вы писали:
J>>Скажем (может, сейчас Сергей Губанов подтянется), почему следующая версия Паскаля называлась Object Pascal, а не Meta Pascal?
К>Я не Сергей, но вообще-то следующая версия паскаля называлась Modula.
Модула — это не новая версия Паскаля, это отдельный язык, как и Оберон (равно как и С++ — это не следующая версия С, а java — это не следующая версия С++).
Например, цитата из википедии (из статьи про Паскаль):
Pascal is based on the ALGOL programming language and named in honor of mathematician and philosopher Blaise Pascal. Wirth subsequently developed Modula-2 and Oberon, languages similar to Pascal.
(из статьи про модулу):
Modula-2 is a general purpose procedural language, sufficiently flexible to do systems programming, but with much broader application. In particular, it was designed to support separate compilation and data abstraction in a straightforward way. Much of the syntax is based on Wirth's earlier and better-known language, Pascal. Modula-2 was designed to be broadly similar to Pascal, with some elements removed and the important addition of the module concept, and direct language support for multiprogramming.
Здравствуйте, jazzer, Вы писали:
E>>Понятие "рулили" очень абстрактное. То, что большинство программистов в то время выполняли свою работу не на Lisp-е вовсе не означает, что на лиспе вообще не делалось важных и ответственных проектов. Думаю, что таки делались и метапрограммирование при этом использовалось на полную катушку.
J>Тогда понятие "бронзовый век" тоже очень абстрактное J>Потому что наверняка кто-нть где-ть открыл возможность работы с железом.
Оно не абстрактное, зато точных дат начала и окончания бронзового века нет -- только приблизительные (с очень высокой дельтой )
J>С++ вполне соответствовал состоянию индустрии на момент его создания.
Вот в этом и вся суть!
C++ возник в ответ на нужды конца семидесятых, начала восьмидесятых годов. И унаследованные оттуда черты лежат в основе этого языка, не выдрать их оттуда и новые не вставить. И еще хорошо, что язык развивался, обрастал новыми возможностями.
Тем не менее, заложенные в него принципы соответствуют тем, уже далеким годам. Сейчас требования изменились, что естественно. Но язык C++ сейчас пинают ногами за то, что он родом из 1985-го (а фактически, еще на пару лет раньше). Мне это кажется, по меньшей мере, странным и я ввязываюсь в подобные флеймы чтобы попытатья такие горячие головы остудить -- не нужно оценивать астролябию с позиции пользователя GPS приемника.
J>Это сейчас все во всех областях приложения программирования рванули в сторону функциональных языков и метапрограммирования.
Да ладно тебе! Это здесь, на RSDN такой мощный поток диферамбов в сторону функциональщины и метапрограммирования, а в "обычной жизни" все по другому. Например, вокруг меня люди заняты обычной работой с использованием самой обычной Java и самого обычного C++. И в этой работе, по большому счету, на фиг не упало ни ФП ни МП -- понятные задачи, готовые инструменты -- бери и делай. Сложности вовсе не в технологиях, а в заказчиках
А высокий уровень интереса (и, соответственно, шума) на RSDN вокруг ФП и МП обуславливается тем, что пишут сюда, как мне кажется, весьма деятельные программисты/студенты/аспиранты, которые легко осваивают материал и стремяться к изучению нового. Ну не достаточно нам обычной, повседневной работы по клепанию EJB компонентов или очередного C++сового агента -- хочется чего-нибудь нового, экзотического, чтобы кровь разогнать. Вот и обсуждают ФП и МП снова и снова, как и остальные серебрянные пули.
J>А было "Дайте нам язык с поддержкой ООП, но чтоб он не тормозил, как Смолтолк, а работал со скоростью Си".
Мне кажется, даже этого не было. Было так. Страуструп думал: "Хочется мне языка с поддержкой ООП, но чтобы он работал со скоростью Си и не жрал столько памяти как ALGOL, и чтобы системным программированием на нем было приятнее заниматься, чем на C". Может так и еще кто-то думал, но у Страуструпа это получилось воплотить в C++. А затем его творением воспользовались те, кто нуждался в подобном инструменте.
J>Раз, как вы утверждаете, был большой запрос на это дело со стороны индустрии и это считалось "базовой вещью"?
J>Неужели я так криво пишу, что меня вообще невозможно понять?
Я не утверждаю, что высокий спрос на метапрограммирование был. Просто для восстановления, скажем так, исторической справедливости говорю, что метапрограммирование сущестовало задолго до появления C++. И использовалось в промышленных проектах (поскольку и сам Lisp в промыщленных проектах использовался). А уж масштабы этого применения на тот момент я вообще не могу оценить. Так же, впрочем, как и масштабы применения метапрограммирования в наши дни. Хотя и кажется мне, что масштабы эти некоторыми горячими головами безбожно завышаются.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, VladD2, Вы писали: VD>>Значит С++ не кросплатформный? У него в стандарте тоже нет переносимого ГУИ. CC>Пардон, WinForms входит в комплект библ .NET. По сути является стандартной библиотекой. В С++ в стандартной библиотеке этого нет. Стандартные библиотеки должны быть переносимы, в противном случае это не кроссплатформенность а геморрой с бантиком. Так что претензия ИМХО мимо кассы...
WinForms в такой же степени стандартная библиотека для CLI, в какой MFC — стандартная библиотека C++.
CLI кроссплатформенна в рамках стандарта ECMA 335 и ISO/IEC 23271
.NET и Mono реализации CLI.
Есть для C++ стандартная GUI-библиотека? Нет. Ну так о чем разговор тогда?
... << RSDN@Home 1.2.0 alpha rev. 655>>
'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
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, FR, Вы писали:
FR>>А лисп и форт системы не чистые?
СГ>А вот пускай лисперы и фортисты это и расскажут. Я за них их работу делать не буду.
Они бы расказали, если бы ты расказал что понимаешь под словом "чистые"
Здравствуйте, konsoletyper, Вы писали:
E>>Но, как я понял, проекты в миллионы строк в компании с низкоквалифицированными программистами на C++ вам вести не приходилось. Так откуда же такая нелюбовь ожесточенная? Что же в нем такого отталкивающего?
K>ИМХО, язык жутковатый. Я уже приводил здесь конструкцию, необходимую для обеспечения модульности (чтобы один и тот же файл не инклюдился два раза). Есть много маленьких мелочей. Например, почему я должен к статическому члену класса обращаться через "::", а не через "."? Зачем дважды дублировать сигнатуру метода в .h и .cpp файлах? Почему чтобы сделать вложенный неймспейс, я не могу использовать точечную нотацию, а должен вкладывать друг в друга несколько блоков? Почему существуют три различных способа приведения типа?
Эти вопросы из той же серии, что и "Почему французы говорят на французком, а англичане -- на английском". Исторически так сложилось и ничего здесь уже не сделаешь. Тем более, что сила привычки здесь играет решающую роль. Мне, например, было не понятно, почему в Java статический метод класса вызывается через ".", а не через "::". Или почему в большинстве языков используется специальные соглашения для атрибутов класса (вроде префикса m_, суффикса _ или записи this.something), когда есть хороший способ в Ruby -- префикс @ -- и имя автоматически считается именем класса.
Так что здесь уместно применить фразу "Чего ржете? Вы еще остальных не видели" (не помню откуда она)
K>Почему метапрограммные навороты выглядят так жутко?
Потому что язык на них не расчитывался. А тем, кто начал их применять вовремя руки не поотрывали.
K>Почему нет нормального способа прикрутить человеческий GC, свойства, события и т.д.
По поводу GC: Страуструп создавал C++ имея опыт работы на языке с автоматической сборкой мусора. Поэтому он принципиально сделал C++ без таковой. И все последствия именно из этого.
По поводу событий: как разработчик одного из событийно-ориентированных фреймоворков я рад, что в языке нет "стандартных" событий. Из-за этого для различных семейств различных задач можно делать различные способы реагирования на события.
K>Наконец, почему, чтобы понять C++, нужно от и до внимательно прочитать Страуструпа, а потом ещё Липпмана?
Вы думаете этого достаточно?
Я сильно сомневаюсь. C++ -- он, имхо, как любой иностранный язык -- можно учить всю жизнь.
K>Но вот беда: есть языки, к которым подобных вопросов не задаётся.
Но, во-первых, вот и славно. Затем же в C++ камнями кидаться. Тем более, что как я понял, C++ вообще лежит далеко в стороне от ваших профессиональных задач и интересов.
И, во-вторых, оставте нам, старикам, нашу любимую игрушку. Ну нравится нам наша музыка, хотя для вас, молодежи, это просто ретро. И мы хотим ее играть, сами себе, в своем доме престарелых. А вы к нам через пару лет присоединитесь со своей музыкой, которую уже кто-то другой будет считать ретро
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
J>>С++ вполне соответствовал состоянию индустрии на момент его создания.
E>Вот в этом и вся суть!
Ну хоть один человек меня понял Теперь можно и умереть
(Кстати, обещанные фотки, только не мои и трехлетней давности: http://www.pbase.com/pcm/movingin, но принципиально, ясно дело, ничего не поменялось)
J>>Это сейчас все во всех областях приложения программирования рванули в сторону функциональных языков и метапрограммирования.
E>Да ладно тебе! Это здесь, на RSDN такой мощный поток диферамбов в сторону функциональщины и метапрограммирования, а в "обычной жизни" все по другому. Например, вокруг меня люди заняты обычной работой с использованием самой обычной Java и самого обычного C++. E>А высокий уровень интереса (и, соответственно, шума) на RSDN вокруг ФП и МП обуславливается тем, что пишут сюда, как мне кажется, весьма деятельные программисты/студенты/аспиранты, которые легко осваивают материал и стремяться к изучению нового.
Ну ты преувеличиваешь (или преуменьшаешь). Не зря же народ делает всякие бусты, да и в СТЛ в каком-то виде функциональщина есть. Да в шарпе всякие делегаты. Так что, имхо, все это витает в воздухе.
J>>Раз, как вы утверждаете, был большой запрос на это дело со стороны индустрии и это считалось "базовой вещью"?
E>Я не утверждаю, что высокий спрос на метапрограммирование был. Просто для восстановления, скажем так, исторической справедливости говорю, что метапрограммирование сущестовало задолго до появления C++.
Да я ж не спорю, что существовало. Я спорю с тем, что это было базовой вещью.
Здравствуйте, jazzer, Вы писали:
J>>>С++ вполне соответствовал состоянию индустрии на момент его создания.
E>>Вот в этом и вся суть! J>Ну хоть один человек меня понял Теперь можно и умереть
Не, давай просто спокойно жить, работать и не обращать внимания на разные buzzword-ы!
J>(Кстати, обещанные фотки, только не мои и трехлетней давности: http://www.pbase.com/pcm/movingin, но принципиально, ясно дело, ничего не поменялось)
Спасибо!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, AVC, Вы писали:
AVC>>Здравствуйте, Plague, Вы писали:
P>>>Хех, как Вы хитро сюда к разговору Вирта прикрутили, это намек на Оберон? Его простота в отсутствии "Синтаксического оверхеда"?
AVC>>Просто там вот это AVC>>http://www.rsdn.ru/Forum/Message.aspx?mid=707886&only=1
AVC>>не нужно. AVC>>Впрочем, это, наверное, так интересно...
J>Демагогия чистой воды.
Где? Конкретному человеку на конкретном примере (его собственном — исключительно для доходчивости) показываю, в чем простота Оберона (раз уж ему стало интересно; не я ведь Оберон помянул): в отсутствии самой потребности писать подобный код.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Hello, jazzer!
You wrote on Mon, 29 Jan 2007 16:59:04 GMT:
dmz>> На Java был бы валидный код — о памяти позаботился бы GC
j> Вот как раз с GC и была проблема. j> Он банально не успевал чистить память, в результате все корилось j> из-за нехватки памяти.
А какой конкретно механизм сборки мусора там использовался?
И не происходило ли это во времена когда еще не было HotSpot?
Здравствуйте, Yuri Khomic, Вы писали:
dmz>>> На Java был бы валидный код — о памяти позаботился бы GC
j>> Вот как раз с GC и была проблема. j>> Он банально не успевал чистить память, в результате все корилось j>> из-за нехватки памяти.
YK>А какой конкретно механизм сборки мусора там использовался?
Понятия не имею, я не джавист.
YK>И не происходило ли это во времена когда еще не было HotSpot?
Нет, это было в прошлом году.
Здравствуйте, dmz, Вы писали:
dmz>Попробуй с его помощью разобрать SQL-запрос в виде строки и добавить в класс поля, dmz>соответствующие его колонкам.
А в чем собственно проблема, кроме сложности написания парсера SQL запроса?! Макрос в Немерле по сути полноценная программа, доступно все, что доступно обычной программе, а в ней хоть к гуглю обращайся за помощью
Здравствуйте, AVC, Вы писали:
AVC>Конкретному человеку на конкретном примере (его собственном — исключительно для доходчивости) показываю, в чем простота Оберона (раз уж ему стало интересно; не я ведь Оберон помянул): в отсутствии самой потребности писать подобный код.
Странно, мне и на С++ нет ни малейшей потребности писать подобный код. Что я делаю не так?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Hello, jazzer!
You wrote on Wed, 31 Jan 2007 09:46:54 GMT:
dmz>>>> На Java был бы валидный код — о памяти позаботился бы GC
j>>> Вот как раз с GC и была проблема. j>>> Он банально не успевал чистить память, в результате все j>>> корилось из-за нехватки памяти.
YK>> А какой конкретно механизм сборки мусора там использовался? j> Понятия не имею, я не джавист.
Здравствуйте, CreatorCray, Вы писали:
CC>Открою тебе страшную тайну: микрософт думает только о том, как продать свои творения и подсадить на них еще больше народу.
Открою тебе еще более страшную тайну: любая корпорация, борющаяся за место на рынке, думает о том, как продать свои творения и подсадить на них больше народу.
Здравствуйте, AndreiF, Вы писали:
AF>И усилению самомнения программиста, который продравшись через горы проблем и заморочек, добирается наконец до решения задачи AF>Никакой другой язык не дает такого удовлетворения — там слишком просто всё делается
Ошибаешься, Лисп на много больше усиливает самомнение
На своем горьком опыте знаю, каждая законченная программа вызывает такой мощный поток эндорфинов, что С++ рядом не валялся
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, CreatorCray, Вы писали:
AVC>>Конкретному человеку на конкретном примере (его собственном — исключительно для доходчивости) показываю, в чем простота Оберона (раз уж ему стало интересно; не я ведь Оберон помянул): в отсутствии самой потребности писать подобный код. CC>Странно, мне и на С++ нет ни малейшей потребности писать подобный код. Что я делаю не так?
Фразу о конкретности адресата, наверное, Вы не заметили.
По поводу указанной потребности — можете обсудить это с Plague.
Впрочем, еще проще считать, что конструкцию if(const==var) злые оберонщики придумали.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Yuri Khomic, Вы писали:
YK>Hello, jazzer! YK>You wrote on Wed, 31 Jan 2007 09:46:54 GMT:
dmz>>>>> На Java был бы валидный код — о памяти позаботился бы GC
j>>>> Вот как раз с GC и была проблема. j>>>> Он банально не успевал чистить память, в результате все j>>>> корилось из-за нехватки памяти.
YK>>> А какой конкретно механизм сборки мусора там использовался? j>> Понятия не имею, я не джавист.
YK>Сложно тогда о чем-то разговаривать
Сложно, а как же
Но я исхожу из того, что люди там в команде были достаточно квалифицированные и знали, что делают. И они наверняка знали и про хот спот, и про механизм (я даже не знал, что в JVM им можно управлять, а оно вот как, оказывается).
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
J>>Опять не пойму, с чем ты споришь. Ты меня хочешь в какой-то флейм втянуть, что ли?
VD>Re[6]: Сложный язык для сложных срограмм.
А, ну так ты споришь со словами, вырванными из контекста. Прочитай выше. Если все равно будет непонятно, о чем я говорил — прочитай мой разговор с eao197 — он в результате смог понять, что я имел в виду
Yuri Khomic wrote: > А какой конкретно механизм сборки мусора там использовался? > И не происходило ли это во времена когда еще не было HotSpot?
Есть такая особенность у Java-вского GC, он может бросать OOM, если
память слишком быстро распределяется (особенно это классно, когда размер
кучи в пару-тройку гигабайт). Лечится тюнингом опций.
Здравствуйте, Cyberax, Вы писали:
C>Gajdalager wrote: >> В теории .Нет кроссплатформенный, а моноплатформенность .Нета происходит >> не от каких-либо просчетов в архитектуре или спецификации, а из-за >> политики МС. C>Вообще-то, я уже как-то флеймил, что из-за некоторых предположений в C>модели памяти .NET — его будет сложно портировать на nccNUMA-машины C>(когда они появятся ).
А чего это за машины? что-то Гугл не слышал... дайте ссылку плиз.
Plague wrote: > C>Вообще-то, я уже как-то флеймил, что из-за некоторых предположений в > C>модели памяти .NET — его будет сложно портировать на nccNUMA-машины > C>(когда они появятся ). > А чего это за машины? что-то Гугл не слышал... дайте ссылку плиз.
non-cache-coherent Non-Uniform-Memory-Access (ищется по "ncc NUMA" — с
пробелом). В частности, это некоторые Альфы и Cell в PS3.
Hello, jazzer!
You wrote on Wed, 31 Jan 2007 10:51:36 GMT:
j>>>>> Вот как раз с GC и была проблема. j>>>>> Он банально не успевал чистить память, в результате все j>>>>> корилось из-за нехватки памяти.
YK>>>> А какой конкретно механизм сборки мусора там использовался? j>>> Понятия не имею, я не джавист.
YK>> Сложно тогда о чем-то разговаривать
j> Сложно, а как же
j> Но я исхожу из того, что люди там в команде были достаточно j> квалифицированные и знали, что делают. И они наверняка знали и про j> хот спот, и про механизм (я даже не знал, что в JVM им можно j> управлять, а оно вот как, оказывается).
Мне это все интересно в свете того, что (по-твоим словам) память не успевала очищаться сборщиком мусора. Если причиной тому был большой размер кучи, то возможно проблема решалась бы включением generational GC и соответствующей настройкой размера young/old generations.
Здравствуйте, Yuri Khomic, Вы писали:
YK>Мне это все интересно в свете того, что (по-твоим словам) память не успевала очищаться сборщиком мусора. Если причиной тому был большой размер кучи, то возможно проблема решалась бы включением generational GC и соответствующей настройкой размера young/old generations.
Вполне возможно, что там реализовался вариант, о котором говорил Cyberax здесь
. Мне говорили, что она падает с OutOfMemory — естественно, я предположил, что это потому, что она не успевала очищаться. А оно вон еще как может, оказывается.
YK>Насчет сборки мусора в HotSpot — вот навскидку, можешь почитать если интересно YK>http://www.javaworld.com/javaworld/jw-01-2002/jw-0111-hotspotgc.html
Здравствуйте, Cyberax, Вы писали:
C>Yuri Khomic wrote: >> А какой конкретно механизм сборки мусора там использовался? >> И не происходило ли это во времена когда еще не было HotSpot? C>Есть такая особенность у Java-вского GC, он может бросать OOM, если C>память слишком быстро распределяется (особенно это классно, когда размер C>кучи в пару-тройку гигабайт). Лечится тюнингом опций.
А каких опций, если не секрет? (Только мне смысл опций, если можно, а не просто названия )
Yuri Khomic wrote: > Мне это все интересно в свете того, что (по-твоим словам) память не > успевала очищаться сборщиком мусора. Если причиной тому был большой > размер кучи, то возможно проблема решалась бы включением generational GC > и соответствующей настройкой размера young/old generations.
Gen. GC в Java весьма сложно отключить
> Насчет сборки мусора в HotSpot — вот навскидку, можешь почитать если > интересно > http://www.javaworld.com/javaworld/jw-01-2002/jw-0111-hotspotgc.html
Механизм HotSpot напрямую к GC не относится.
jazzer wrote: > C>Есть такая особенность у Java-вского GC, он может бросать OOM, если > C>память слишком быстро распределяется (особенно это классно, когда размер > C>кучи в пару-тройку гигабайт). Лечится тюнингом опций. > А каких опций, если не секрет? (Только мне смысл опций, если можно, а не > просто названия )
Ооо... Ты просишь тайны шаманства раскрыть?
В общем, там есть несколько алгоритмов (parallel GC, incremental и т.п.)
и у них куча опций. В основном, надо смотреть на MaxPermSize
(максимальный размер permanent-кучи), кроме того, оказалось очень важно
найти то место, с которого GC должен исполнить полный цикл GC (сейчас не
вспомню опцию). Ну и очень помогла опция "XX:SurvivorRatio", которая
указывает какой делать размер для старой кучи.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Хм, MS так не думает. CC>Открою тебе страшную тайну: микрософт думает только о том, как продать свои творения и подсадить на них еще больше народу.
Естественно, но подумай почему они теперь продвигают связку C# + .NET + XNA, а не C++ + COM + DirectX как раньше. Значит у новой технологии есть определенные преимущества.
Здравствуйте, dmz, Вы писали:
dmz>Мое утверждение: C++ не нужен для разработки серверов в 99.9% случаев. СУБД — это как раз оставшийся процент случаев. Разработка на нем дольше, сложнее, требует более высокой квалификации и не дает на этом классе задач никаких особенных преимуществ. С удовлетворением могу заметить, что эту точку зрения разделяют многие — например, dmz>Ericsson.
Вообщето некоторое время искал и нашел, Oracle из соображений портируемости и стабильности написан на чистом С. И на С++ переписывать даже и не думают.
Hello, Cyberax!
You wrote on Wed, 31 Jan 2007 11:36:25 GMT:
>> Мне это все интересно в свете того, что (по-твоим словам) память >> не успевала очищаться сборщиком мусора. Если причиной тому был >> большой размер кучи, то возможно проблема решалась бы включением >> generational GC и соответствующей настройкой размера young/old >> generations. C> Gen. GC в Java весьма сложно отключить
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, VladD2, Вы писали:
VD>>Значит С++ не кросплатформный? У него в стандарте тоже нет переносимого ГУИ. CC>Пардон, WinForms входит в комплект библ .NET. о сути является стандартной библиотекой.
В стандарт CLI она не входит. Так что она настолько же "стандартна" как, например, MFC для С++.
Просто MS в своей реализации CLI под названием .NET поставляет больше библиотек, чем есть в стандарте. Конечно, MS пудрит мозги помещая их в пространство имен "System.", хотя на самом деле их место в "Microsoft.".
Стандарт (в редакции ISO/IEC 23271:2006(E)) требует только наличия следующих библиотек (там правда еще есть ньюансы с профилями):
5 The standard libraries:
5.1 General comments
5.2 Runtime infrastructure library
5.3 Base Class Library (BCL)
5.4 Network library
5.5 Reflection library
5.6 XML library
5.7 Extended numerics library
5.8 Extended array library
5.9 Vararg library
5.10 Parallel library
CC> В С++ в стандартной библиотеке этого нет. Стандартные библиотеки должны быть переносимы,
Они и переносимы. Проблемы с .NET-технологиями от MS (WinForms, ASP.NET, ADO.NET, WCF, WWF, WPF). Но если пользоваться только тем что есть в Mono, то получим кроссплатформенность в рамках Mono. Т.е. сборка будет запускаться на любой платформе, где есть Mono.
VD>>А в Моно есть поддержка GTK. CC>GTK есть в стандартных библиотеках .NET? Нету? Тогда мимо кассы...
В стандартных библиотеках CLI нет вообще ни слова о GUI.
CC>Реализация VM для дотнета только одна.
Как раз VM то целых 4 : MS.NET, Rotor, Mono, dotGNU, и Mono запускается очень даже много где (вплоть до всяких Nokia 770), а вот библиотек больше всего у MS.NET.
AVC>Фразу о конкретности адресата, наверное, Вы не заметили. AVC>По поводу указанной потребности — можете обсудить это с Plague. AVC>Впрочем, еще проще считать, что конструкцию if(const==var) злые оберонщики придумали.
На самом деле тот код я написал чисто для того чтобы попробовать — "а можно ли так?". Попробовал, получилось, но с оговорками... НИ В КОЕМ СЛУЧАЕ не реккомендую использовать в реальном проекте, а включить Варнинги компилятора. И варнинги — это не значит, что так не нужно писать, а что, возможно, есть ошибка. Использование = в условиях — совместимость с языком С.
PS: это, кстати, 2004й год.. 2.5 года назад... мои личные извращения... =)
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>Главным образом я хочу получить ответ на свой вопрос: E>>
E>>Вот тут не очень понял. Ты имеешь ввиду, что сложные кроссплатформенные системы нельзя писать на C++? Или что тем, кто не пишет сложных кроссплатформенных систем, C++ с его фичами не нужен?
E>>поскольку твою фразу о разработке сложных кроссплатформенных систем я не понял
VD>Мне кажется, он имел в виду, что на С++ очень сложно писать переносимый код.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Естественно, но подумай почему они теперь продвигают связку C# + .NET + XNA, а не C++ + COM + DirectX как раньше. Значит у новой технологии есть определенные преимущества.
Это все поможет продавать железо партнеров, висту и xbox360 + подсаживание на иглу .NET толпы прогеров.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Открою тебе страшную тайну: микрософт думает только о том, как продать свои творения и подсадить на них еще больше народу.
Не надо так плохо думать о народе, у народа тоже есть голова, народ не будет покупать лажу. Скорее майкрософту надо напрягаться, пытаться выпускать качественные продукты, а то ведь у народа есть и альтернативы от конкурентов.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Kisloid, Вы писали:
K>Здравствуйте, AndreiF, Вы писали:
AF>>И усилению самомнения программиста, который продравшись через горы проблем и заморочек, добирается наконец до решения задачи AF>>Никакой другой язык не дает такого удовлетворения — там слишком просто всё делается
K>Ошибаешься, Лисп на много больше усиливает самомнение K>На своем горьком опыте знаю, каждая законченная программа вызывает такой мощный поток эндорфинов, что С++ рядом не валялся
Здравствуйте, Kisloid, Вы писали:
K>Здравствуйте, CreatorCray, Вы писали:
CC>>Открою тебе страшную тайну: микрософт думает только о том, как продать свои творения и подсадить на них еще больше народу.
K>Не надо так плохо думать о народе, у народа тоже есть голова, народ не будет покупать лажу. Скорее майкрософту надо напрягаться, пытаться выпускать качественные продукты, а то ведь у народа есть и альтернативы от конкурентов.
К сожалению эту "голову", мне кажется, ты преувеличиваешь. Иначе бы не было целого вороха "исторически сложившихся" решений, кривых еле работающих, где порой поддержка выходит дороже переписывания по-новому. Пример — Y2K, хотябы.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>А как J? Забористо? А Haskell?
J незнаю, ни разу в глаза не видел. А вот Хаскель к сожалению хватило времени только обзорно посмотреть, но в целом понравилось, следующим по очереди к изучению как раз и стоит Хаскель.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Курилка, Вы писали:
К>К сожалению эту "голову", мне кажется, ты преувеличиваешь. Иначе бы не было целого вороха "исторически сложившихся" решений, кривых еле работающих, где порой поддержка выходит дороже переписывания по-новому. Пример — Y2K, хотябы.
Если уж говорить про кривые и еле работающие исторически сложившиеся решения, то один из венцов таких творений — boost — никакого отношения к корпорациям не имет
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, Курилка, Вы писали:
К>>К сожалению эту "голову", мне кажется, ты преувеличиваешь. Иначе бы не было целого вороха "исторически сложившихся" решений, кривых еле работающих, где порой поддержка выходит дороже переписывания по-новому. Пример — Y2K, хотябы.
AF>Если уж говорить про кривые и еле работающие исторически сложившиеся решения, то один из венцов таких творений — boost — никакого отношения к корпорациям не имет
Вообще-то я про корпорации ничего не говорил
В корпорациях тоже люди, кстати работают...
Здравствуйте, eao197, Вы писали:
E>По поводу GC: Страуструп создавал C++ имея опыт работы на языке с автоматической сборкой мусора. Поэтому он принципиально сделал C++ без таковой. И все последствия именно из этого.
Ну и не только. Просто обязательный GC очень сузил бы сферу применения, а опциональных Страустурп ждал от компиляторов.
E>По поводу событий: как разработчик одного из событийно-ориентированных фреймоворков я рад, что в языке нет "стандартных" событий. Из-за этого для различных семейств различных задач можно делать различные способы реагирования на события.
K>>Наконец, почему, чтобы понять C++, нужно от и до внимательно прочитать Страуструпа, а потом ещё Липпмана?
E>Вы думаете этого достаточно? E>Я сильно сомневаюсь. C++ -- он, имхо, как любой иностранный язык -- можно учить всю жизнь.
K>>Но вот беда: есть языки, к которым подобных вопросов не задаётся.
E>Но, во-первых, вот и славно. Затем же в C++ камнями кидаться. Тем более, что как я понял, C++ вообще лежит далеко в стороне от ваших профессиональных задач и интересов.
E>И, во-вторых, оставте нам, старикам, нашу любимую игрушку. Ну нравится нам наша музыка, хотя для вас, молодежи, это просто ретро. И мы хотим ее играть, сами себе, в своем доме престарелых. А вы к нам через пару лет присоединитесь со своей музыкой, которую уже кто-то другой будет считать ретро
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, VladD2, Вы писали:
VD>>Значит С++ не кросплатформный? У него в стандарте тоже нет переносимого ГУИ. CC>Пардон, WinForms входит в комплект библ .NET. По сути является стандартной библиотекой. В С++ в стандартной библиотеке этого нет.
MFC входит в комплект VC, и по сути является стандартной библиотекой.
Чувствуещь свою логику?
WinForms стандартной библиотекой не является. Он является частной библиотекой МС.
В стандарт входит очень небольшая часть библиотек дотента и она практически полностью реализована в Моно.
VD>>А в Моно есть поддержка GTK. CC>GTK есть в стандартных библиотеках .NET? Нету? Тогда мимо кассы...
А что QT или MWC есть? А может VCL?
Ты шутник одако. Или с логикой большие нелады.
CC>Стоп! Вот отсюда помедленнее: моно все таки это .NET под никсы или это что то отдельное, но бинарно совместимое?
.NET — это зарегистрированная торговая марка МС. .NET Framevork — это название выпускаемого МС продукта реализующего стандарты ECMA им же и введенные.
Моно — реализация этих стандартов почти независимыми (от Новела) программистами.
Моно и .NET полностью совместимы по формату бинарных файлов, реализуют одни и те же стандарты и обеспечивают бинарную переносимость исполняемых модулей. Таки образом Моно и .NET позволяют создавть софт который будет работать на них без перекомпиляции.
Все тоже самое творится в мире С++-компиляторов, только в добавок совместимость обеспечивается исключительно на уровне исходников и очень плохо.
CC> Если отдельное то при чем тут вообще Моно к портируемости .NET? То, что моно переносим — отдельная песТня. Речь изначально шла исключительно про кроссплатформенность .NET
Практически все что написано под Моно будет работать на Дотнете. "Практически" я упомянул потому как мы живем в реальном мире и в любой программе есть баги.
VD>>Вторая — многим тем кто выбирает технологии МС просто начхать и растереть на все что делается пол Уних в общем, и под Линукс в частности. CC>Т.е. все утверждения что гипотетическая кроссплатформенность .NET это ее бааальшой плюс можно сразу отправлять в void, уже по причине полной ненужности этой самой кроссплатформенности.
То есть реальная переносимость дотнетного кода откровенно не колышит большинство тех кто использует .NET. И это не имеет никакого отношения к его переносимости.
CC>Более правильным было бы сказать "только в рассчете на один из компиляторов С++,
Да, я опечатался. Хотел написать "в рассчете на VC++".
CC>Реализация VM для дотнета только одна. Компилеров С++ же много, они бинарно несовместимы в большинстве своем. Пиши под один GCC на все нужные тебе платформы и будет тебе щасте!
Пиши под Моно и щастья буде гораздо больше, а зад менее порепаным.
А главное, не притягивай за уши совсем уж никудышные аргументы.
VD>>И сам процесс поддержания прогаммы способной одинаково хорошо работать на разных платфомах сложнее. CC>Гм. x86, PS2, XBOX — наше двигло вроде нормально на них работало, Один код, только разделение по hardware dependent уровню и все.
Скромный список вопросов.
1. Ты лично занимался обеспечением работоспособности "вашего двигла" на этих платформах?
2. В какой игре можно увидить "ваше двигло"?
3. Сколько лет вы его разрабатываете?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
VD>>Мне кажется, он имел в виду, что на С++ очень сложно писать переносимый код.
Ш>Это утверждение противоречит моему опыту.
А какой у тебя опыт написания переносимых программ на других языка?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dmz, Вы писали:
VD>>Попробуй, например, с его помощью прочитать что-то из внешнего файла.
dmz>Попробуй с его помощью разобрать SQL-запрос в виде строки и добавить в класс поля, dmz>соответствующие его колонкам.
J>А, ну так ты споришь со словами, вырванными из контекста. Прочитай выше. Если все равно будет непонятно, о чем я говорил — прочитай мой разговор с eao197 — он в результате смог понять, что я имел в виду
Нет, я указываю на дремучие заблуждения одно из товарищей.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndreiF, Вы писали:
AF>И усилению самомнения программиста, который продравшись через горы проблем и заморочек, добирается наконец до решения задачи AF>Никакой другой язык не дает такого удовлетворения — там слишком просто всё делается
Судя по маниакальности некоторых Лисперов у Лиспа это удается даже лучше.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, konsoletyper, Вы писали:
>>> А в кваке нет ничего такого, что требовало бы четырёхэтажных >>> скриптов. Фактически, почти вся игра состоит из одного движка. Движки >>> действительно писать можно только на C++, а жаль . Может быть, в будущем >>> что-то изменится. C>>А зачем?
K>Затем, что в будущем игры должны становиться красивее, эффектнее, реалистичнее. Для этого нужен будет мощный движок. Вот тогда мы все и поймём, зачем.
Мощный — это как?
ИМХО С++ довольно неплохо подходит для создания графических движков, это одна из тех задач, откуда его будет очень не просто вытеснить .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, dmz, Вы писали:
dmz> Из этого определенным образом следует, что при разработке серверов БД нам нужна вся dmz> производительность до капли — это критично. dmz> Но тут, внимание, вопрос — а на С++ ли они пишутся? Не на C ли, случаем?
Как минимум Firebird на С++.
Здравствуйте, VladD2, Вы писали:
VD>MFC входит в комплект VC, и по сути является стандартной библиотекой.
С каких пор VC стало стандартом С++ ? VD>WinForms стандартной библиотекой не является. Он является частной библиотекой МС.
Равно как и MFC в таком случае.
CC>>GTK есть в стандартных библиотеках .NET? Нету? Тогда мимо кассы... VD>А что QT или MWC есть? А может VCL? VD>Ты шутник одако. Или с логикой большие нелады.
См свою же тираду про MFC. Вопрос про логику переадресую назад.
CC>>Стоп! Вот отсюда помедленнее: моно все таки это .NET под никсы или это что то отдельное, но бинарно совместимое? VD>.NET — это зарегистрированная торговая марка МС. .NET Framevork — это название выпускаемого МС продукта реализующего стандарты ECMA им же и введенные.
Т.е. микрософт придумала стандарт и сама же под него и пишет.
VD>А главное, не притягивай за уши совсем уж никудышные аргументы.
Это не являлось аргументом
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, VladD2, Вы писали:
VD>Нет, я указываю на дремучие заблуждения одно из товарищей.
Товарищ — это я? На какие "дремучие заблуждения"? Что препроцессор в С — это метапрограммирование? Я, по-моему, внятно объяснил, что я имел в виду. И не один раз. Напоминаю для тех, кому лень подняться на два сообщения назад: флейм начался из-за утверждения, что рефлексия — это базовая вещь, и ее отсутствие ставилось в упрек С++. Цитата:
В C++ даже нет такого базового свойства как рефлексия. Дальше можно не продолжать.
Если тебе на эти объяснения наплевать и ты предпочитаешь цепляться к словам, выдранным из контекста, прикрываясь при этом смайликами — чести тебе это не делает.
Здравствуйте, eao197, Вы писали:
E> Или почему в большинстве языков используется специальные соглашения для атрибутов класса (вроде префикса m_, суффикса _ или записи this.something),
Немного оффтопа. Это, конечно, дело вкуса, но я вот не могу нормально читать код, в котором члены класса начианиются с m_ или _. ИМХО, это нечитабельно. Только просьба ко всем: флейма не надо разжигать.
K>>Почему нет нормального способа прикрутить человеческий GC, свойства, события и т.д.
E>По поводу GC: Страуструп создавал C++ имея опыт работы на языке с автоматической сборкой мусора. Поэтому он принципиально сделал C++ без таковой. И все последствия именно из этого.
Но почему же он не прдусмотрел более-менее человеческого способа прикрутить опициональный GC на уровне библиотек (то, что имеется, ИМХО, выглядит страшновато).
K>>Наконец, почему, чтобы понять C++, нужно от и до внимательно прочитать Страуструпа, а потом ещё Липпмана?
E>Вы думаете этого достаточно? E>Я сильно сомневаюсь. C++ -- он, имхо, как любой иностранный язык -- можно учить всю жизнь.
Ну, это конечно. Всего знать невозможно. Но базу надо иметь. А базу, как показал мой опыт, можно получить, осилив именно эти книжки (и нынче ещё Александреску), ну и, конечно, что-нибудь серьёзное написав.
K>>Но вот беда: есть языки, к которым подобных вопросов не задаётся.
E>Но, во-первых, вот и славно. Затем же в C++ камнями кидаться. Тем более, что как я понял, C++ вообще лежит далеко в стороне от ваших профессиональных задач и интересов.
Ну так я и не кидаюсь. Я же не становлюсь посреди улицы и не кричу "C++ — отсто-о-о-ой" (на самом деле я так не считаю). Просто порой я слышу фразу вроде "данную задачу удобнее решать на C++, потому что он уже 20 лет рулит, и ещё 100 лет рулить будет". Ну нельзя так. Если в C++ есть какие-то изъяны, то "крутизна" C++ не повод, чтобы это терпеть. Хотелось бы, чтобы ситуация изменилась к лучшему. Тут я вижу три выхода:
1. Отказ разработчиков C++ от совместимости с некоторой частью lagacy-кода, за счёт этого — очистка C++ от всякого "мусора".
2. Разработка языка, способного заменить C++ в области разработки высокопроизводительных программ.
3. Развитие managed-сред, так, чтобы они могли довольно сносно решать "низкоуровневые" задачи.
По крайней мере, что-то должно улучшаться, на месте стоть нельзя. В том числе это касается лично меня. А то вдруг я попаду, скажем, в сферу разработки игр, и меня затсавят писать на C++, когда есть что-то лучшее?
Кстати, порой мне приодится писать на C++. В основном из-за того, что приходится бороться с криворукостью индусов, писавших некоторые части фрэймворка.
E>И, во-вторых, оставте нам, старикам, нашу любимую игрушку. Ну нравится нам наша музыка, хотя для вас, молодежи, это просто ретро. И мы хотим ее играть, сами себе, в своем доме престарелых. А вы к нам через пару лет присоединитесь со своей музыкой, которую уже кто-то другой будет считать ретро
Да играйтесь на здоровье. C++ не такой уж плохой язык. Просто он уже старый, и объективно в нём понакопилось всякого мусора. Вот и раздражает, когда мусор хотят за достоинство выдать.
Здравствуйте, dr.Chaos, Вы писали:
DC>Мощный — это как?
Это так, как мы себе и прдставить не можем. Вот рассказал бы кто-то про нынешние 3D-игры лет 20 назад, его бы психом посчитали.
DC>ИМХО С++ довольно неплохо подходит для создания графических движков, это одна из тех задач, откуда его будет очень не просто вытеснить .
Да на ассемблере тоже можно неплохой движок написать. Просто сейчас C++ — это лучшее, что подходит для данной задачи. Но надо понимать, что это не навсегда.
Здравствуйте, CreatorCray, Вы писали:
CC>Т.е. микрософт придумала стандарт и сама же под него и пишет.
Совершенно верно. При том она так не только с CLI поступает. Та же самая ситуация и с Open Office XML, XPS да и еще много с чем другим, тот же самый XML в значительной степени продвигался усилиями MS (хотя там и других заинтересованных лиц было много).
Дело в том, что стандарт дает больше солидности, фиксирует ABI/API, а в некоторых случаях (например, в государственных органах ЕС) открытость стандарта файлов является обязательным условием для его использования.
Да, кстати, это оказывает давление и на других, из-за угрозы стандартизации XPS Adobe решилась таки сделать PDF открытым форматом:
Здравствуйте, konsoletyper, Вы писали:
K>Немного оффтопа. Это, конечно, дело вкуса, но я вот не могу нормально читать код, в котором члены класса начианиются с m_ или _. ИМХО, это нечитабельно. Только просьба ко всем: флейма не надо разжигать.
Тоже из разряда личных пристрастий -- мне, например, неудобно читать код в CamelCase -- очень сильно устают глаза. Поэтому стараюсь пользоваться lower_case. Но, к сожалению, в современных языках CamelCase просто таки стандарт де-факто. Причем попытки даже простого возражения встречаются в штыки, мол code convention и все такое.
K>Ну так я и не кидаюсь. Я же не становлюсь посреди улицы и не кричу "C++ — отсто-о-о-ой" (на самом деле я так не считаю).
K>Просто порой я слышу фразу вроде "данную задачу удобнее решать на C++, потому что он уже 20 лет рулит, и ещё 100 лет рулить будет". Ну нельзя так. Если в C++ есть какие-то изъяны, то "крутизна" C++ не повод, чтобы это терпеть. Хотелось бы, чтобы ситуация изменилась к лучшему. Тут я вижу три выхода:
K> 1. Отказ разработчиков C++ от совместимости с некоторой частью lagacy-кода, за счёт этого — очистка C++ от всякого "мусора".
Не, так не получится. В принципе. Поскольку ценность legacy кода нельзя преуменьшать.
K> 2. Разработка языка, способного заменить C++ в области разработки высокопроизводительных программ.
В этом плане интересно, что выйдет из D. Как раз очищенный от проблем C++ наследник. После C++ он очень легко осваивается.
K> 3. Развитие managed-сред, так, чтобы они могли довольно сносно решать "низкоуровневые" задачи.
Так это и сейчас уже идет очень быстрыми темпами. В некоторых вещах управляемые языки уже давно рвут C++ по производительности. А вот для очень уж низкоуровневых задач как раз управляемость и является помехой.
Выходит, что два пункта из ваших трех уже выполняются
K>По крайней мере, что-то должно улучшаться, на месте стоть нельзя. В том числе это касается лично меня. А то вдруг я попаду, скажем, в сферу разработки игр, и меня затсавят писать на C++, когда есть что-то лучшее?
Поверьте, если не вестись на пропаганду местных .NET евангелистов и не зачитываться экстремалами от C++ (Александреску того же), то на C++ можно писать очень даже спокойно, качественно и не напрягаясь.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
VD>>>Мне кажется, он имел в виду, что на С++ очень сложно писать переносимый код.
Ш>>Это утверждение противоречит моему опыту.
VD>А какой у тебя опыт написания переносимых программ на других языка?
Здравствуйте, Tonal-, Вы писали:
dmz>> Из этого определенным образом следует, что при разработке серверов БД нам нужна вся dmz>> производительность до капли — это критично. dmz>> Но тут, внимание, вопрос — а на С++ ли они пишутся? Не на C ли, случаем? T>Как минимум Firebird на С++.
MS SQL Server вроде тоже.
now playing: Boards of Canada — Telephasic Workshop
Yuri Khomic wrote: > C> Gen. GC в Java весьма сложно отключить > Сорри, incremental GC хотел написать.
Его как раз отключать не надо, так как он сильно помогает уменьшить
частоту полных сборок.
> C> Механизм HotSpot напрямую к GC не относится. > Не совсем понял. Разве то, что понимается под HotSpot не включает в себя > generational GC?
HotSpot — это механизм перекомпиляции кода "на лету", по результатам
профилирования. Непосредственно к GC он отношения не имеет, в JRE от SUN
есть несколько независимых алгоритмов GC.
Андрей Хропов wrote: > 5 The standard libraries: > 5.1 General comments > * > 5.2 Runtime infrastructure library > 5.3 Base Class Library (BCL) > 5.4 Network library > 5.5 Reflection library > 5.6 XML library > 5.7 Extended numerics library > 5.8 Extended array library > 5.9 Vararg library > 5.10 Parallel library > *
Это не сильно больше, чем в новом Стандарте С++.
То есть, как и на C/С++ писать переносимый код на стандартном языке — не
получится.
konsoletyper wrote: > C>Вообще, в тех же Q1/2/3 скрипты — это просто входные данные, как и > C>шейдеры или текстуры. > Ага, а native-код — это просто входные данные для процессора.
Ну да. Только процессор — это уже не software.
Люди, но неужели вы до сих пор не поняли, что на с# нельзя писать программы с нетривиальной логикой просто потому, что он для этого не предназначен? Он просто убог для этого.
Simple data flow — да, но не больше.
Одно отсутствие const параметров методов — это убийство.
Я это говорю, исходя из личного опыта. У меня "эйфория" от него прошла довольно быстро.
Здравствуйте, jazzer, Вы писали:
J> На какие "дремучие заблуждения"?
А метапрограммирование — штука сравнительно новая.
...
Ты не согласен? Старая? И когда же метапрограммирование начало рассматриваться и применяться как полноценный метод программирования наряду с другими? До рождения С++?
Все это дремучие заблуждения и их следствия. А вызванно это все тем, что ты считаешь что некоторые вещи появились тогда когда они попали в область твого видния (определяемого в основном С++-ом).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Андрей Хропов wrote: >> 5 The standard libraries: >> 5.1 General comments >> * >> 5.2 Runtime infrastructure library >> 5.3 Base Class Library (BCL) >> 5.4 Network library >> 5.5 Reflection library >> 5.6 XML library >> 5.7 Extended numerics library >> 5.8 Extended array library >> 5.9 Vararg library >> 5.10 Parallel library >> * C>Это не сильно больше, чем в новом Стандарте С++.
В каком? который 0x? Так он еще когда выйдет.
C>То есть, как и на C/С++ писать переносимый код на стандартном языке — не C>получится.
Почему? Да, стандарт не охватывает все, что есть в MS.NET. Но тем не менее Monoвцы так или иначе стараются создать соответствующие библиотеки. Во многом они уже есть. Или можно пользоваться альтернативными (тот же Gtk#).
Также как и на C++ можно писать переносимый код если пользоваться только переносимыми библиотеками. Разница в том, что в С++ придется перекомпилировать каждый раз под новую платформу, а то и компилятор.
Стандарт должен обеспечивать возможность простой интеграции библиотек и базовую функциональность. Все остальное — в портабельные библиотеки.
Здравствуйте, Константин Л., Вы писали:
КЛ>Люди, но неужели вы до сих пор не поняли, что на с# нельзя писать программы с нетривиальной логикой просто потому, что он для этого не предназначен?
А где в предыдущем сообщении VladD2 говорил про C#?
КЛ> Он просто убог для этого. Программы с нетривиальной логикой можно писать на любом Тьюринг-полном языке. На C, который прост как табуретка, вон Oracle всякие написаны.
КЛ>Одно отсутствие const параметров методов — это убийство.
Ну соглашусь, что это недостаток.
С другой стороны и у C++ много косяков. Как насчет отсутствия override?
Также можно сказать, что так как в C++ нет GС, то писать на нем — это убийство .
Ты не согласен? Старая? И когда же метапрограммирование начало рассматриваться и применяться как полноценный метод программирования наряду с другими? До рождения С++?
VD>Все это дремучие заблуждения и их следствия. А вызванно это все тем, что ты считаешь что некоторые вещи появились тогда когда они попали в область твого видния (определяемого в основном С++-ом).
Вынужден констатировать, что дискуссия превратилась во флейм и потеряла смысл.
Ты мои объяснения слышать не хочешь, видимо, принципиально их не читаешь. Цепляешься к словам, вырванным из контекста.
Всё, что я хотел сказать, я уже сказал.
Все, кто хотели понять, о чем я говорил, имели для этого все возможности и даже ими воспользовались.
Ты этого делать не хочешь, даже после обяснений, данных лично тебе.
Счастливо оставаться.
Андрей Хропов wrote: > C>Это не сильно больше, чем в новом Стандарте С++. > В каком? который 0x? Так он еще когда выйдет.
Через два года. Следующий ISO-стандарт для C# тоже еще не близко.
> C>То есть, как и на C/С++ писать переносимый код на стандартном языке — не > C>получится. > Почему? Да, стандарт не охватывает все, что есть в MS.NET. Но тем не > менее Monoвцы так или иначе стараются создать соответствующие > библиотеки. Во многом они уже есть. Или можно пользоваться > альтернативными (тот же Gtk#).
Ну это точно такая же ситуация, как и с С++. Необходимо будет
тестировать на совместимость со всеми средами так же, как и в случае с
С++ требуется тестировать с разными компиляторами.
> Также как и на C++ можно писать переносимый код если пользоваться только > переносимыми библиотеками. Разница в том, что в С++ придется > перекомпилировать каждый раз под новую платформу, а то и компилятор.
Ну так и в C# точно так же, используешь какой-нибудь системно-зависимый
контрол — и привет портируемости.
> Стандарт должен обеспечивать возможность простой интеграции библиотек и > базовую функциональность. Все остальное — в портабельные библиотеки.
Если нет стандарта на библиотеки — то будет зоопарк (собственно, он УЖЕ
есть).
Вот в Java, фактически, такой стандарт есть — это Sun JDK, который есть
на куче платформ. А сейчас вообще открытым стал.
Здравствуйте, Шахтер, Вы писали:
VD>>А какой у тебя опыт написания переносимых программ на других языка?
Ш>Речь шла о C++. Причем тут другие языки?
Не допускаешь, что то что ты считаешь нормальным в сравнении с другим языком может оказаться ужасно сложно и медленно?
Другими словами, не допускаешь, что делов в твоей неверной оценке?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tonal-, Вы писали:
T>Чем этот код плох?
Тем что его очень сложно понять. А ведь это совершенно примитивный пример. Реальные грамматики куда сложее.
Лично я предпочел бы полностью декларативную грамматику
Здравствуйте, CreatorCray, Вы писали:
VD>>MFC входит в комплект VC, и по сути является стандартной библиотекой. CC>С каких пор VC стало стандартом С++ ? VD>>WinForms стандартной библиотекой не является. Он является частной библиотекой МС. CC>Равно как и MFC в таком случае.
Значит ты согласен, что вхождение библиотеки в комплект поставки продукта от МС еще не означает, что библиотека становится стандратной?
Я тебе просто продемонстрировал твои же двойные стандарты. Ведь ты не считаешь С++ непереносимым в следствии того, что у него нет стандартной библиотеки ГУИ? Ну, так почему же точно такой же факт в CLI ты склонен считать основанием для не пререносимости?
Переносимая ГУИ-библиотека есть. Это GTK#. Стало быть переносимый ГУИ создавать можно. Качество, ксатати, будет ни хуже чем у переносимых ГУИ-С++-библиотек.
CC>>>Стоп! Вот отсюда помедленнее: моно все таки это .NET под никсы или это что то отдельное, но бинарно совместимое? VD>>.NET — это зарегистрированная торговая марка МС. .NET Framevork — это название выпускаемого МС продукта реализующего стандарты ECMA им же и введенные. CC>Т.е. микрософт придумала стандарт и сама же под него и пишет.
Нет, просто ты высказываешь мнение высосанное из пальца. В вопросах стандартов ты не разбираешся, но о ни х судишь.
Для самобразования читай про CLI и стандарты ECMA/ISO. Они доступны публично.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
КЛ>Люди, но неужели вы до сих пор не поняли, что на с# нельзя писать программы с нетривиальной логикой просто потому, что он для этого не предназначен? Он просто убог для этого. КЛ>Simple data flow — да, но не больше.
КЛ>Одно отсутствие const параметров методов — это убийство.
КЛ>Я это говорю, исходя из личного опыта. У меня "эйфория" от него прошла довольно быстро.
Как ты думаешь, чего стоит твой опыт после таких заявлений?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>не нужно оценивать астролябию с позиции пользователя GPS приемника.
+1 Согасись, что так же глупо использовать астролябию в наше время для навигации по местности. Вот об этом люди и говорт. С++ из 85-го. С теми концепцияи которые были хороши тогда. Но используют его сейчас и с теми концепциями (плюс немного новых) что были тогда. Вот и выходит, что ты предлагаешь не говорить о том, что современные люди используют доисторические инструменты.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, konsoletyper, Вы писали:
K>На C#/Java пока не время. Экспериментировал с C# + ManagedDX. Пока слабовато, для серьёзных игр не потянет. А Pascal он же слабее C++.
Да уж несколько игр впустили на C# ведь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Мощный — это как?
Мощьный — это значит фунциональный, удобный надежный и в меру быстрый.
DC>ИМХО С++ довольно неплохо подходит для создания графических движков, это одна из тех задач, откуда его будет очень не просто вытеснить .
Это заблуждение. С++ уже ни для чего кроме возни с битами не подходит хорошо.
Тут как-то пробегала ссылка на презентацию ролов создающих (если не ошибаюсь) новый Анрлиэл. Там как раз говорилось, что С++ не удоволетворяет современных потребностей и что нужен новый язык. Описывлись требования к этому новому языку. И что забавно большинство из этих требований удивительно пересекались с Немерле.
Reliability
Error-prone language / type system leads to wasted effort finding trivial bugs
Significantly impacts productivity Concurrency
Hardware supports 6-8 threads
C++ is ill-equipped for concurrency
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jazzer, Вы писали:
J>Вынужден констатировать, что дискуссия превратилась во флейм и потеряла смысл.
Ты был лучше научился признавать свои ошибки.
J>Ты мои объяснения слышать не хочешь, видимо, принципиально их не читаешь. Цепляешься к словам, вырванным из контекста.
Какого еще контекста?
J>Всё, что я хотел сказать, я уже сказал.
Это точно. Все от души посмеялись.
J>Все, кто хотели понять,
Во! Ключевое слово "хотел". Вот не хочешь ты понять, что метапрограммирование было за 100 лет до С++, и все тебе.
J>Ты этого делать не хочешь, даже после обяснений, данных лично тебе. J>Счастливо оставаться.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jazzer, Вы писали:
J>Спасибо за экскурс , но что, разве все программисты после этого сразу сказали: "Вау, как это круто, эй, если кто тут соберется разрабатывать новый язык — имейте в виду, если в нем не будет такой базовой вещи как квази-цитирование, он нафиг никому не будет нужен"?
А какое отношение имеет "Вау!" от "всех программистов" к истории метапрограммирования вообще и истории квазицитирования в частности?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, jazzer, Вы писали:
K>>Не надо подменять понятия. К чему эти впадения в среднетяжмаш? Речь шла не о промышленности а о новизне — и в этом смысле метапрограммирование скорее всего старее, чем ООП.
J>нет, изначально речь не о новизне, а о том, что это была общеизвестная базовая вещь во времена создания С++.
Не путай два термина: "метапрограммирование" вообще и "метапрограммирование на шаблонах [C++]".
Первому — много-много лет. Второму — сам понимаешь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, jazzer, Вы писали:
J>>Спасибо за экскурс , но что, разве все программисты после этого сразу сказали: "Вау, как это круто, эй, если кто тут соберется разрабатывать новый язык — имейте в виду, если в нем не будет такой базовой вещи как квази-цитирование, он нафиг никому не будет нужен"?
ГВ>А какое отношение имеет "Вау!" от "всех программистов" к истории метапрограммирования вообще и истории квазицитирования в частности?
Абсолютно никакого.
Это имеет отношение исключительно к упреку в адрес С++ за то, что он не имеет такой "базовой вещи" как рефлексия. Во времена создания С++ это базовой вещью ("вау" от "всех программистов") не было. Также как и исчисление бесконечно малых не было базовой вещью во времена Зенона.
Смотри переписку с еао197, я уже устал по 10-му разу повторять.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, jazzer, Вы писали:
K>>>Не надо подменять понятия. К чему эти впадения в среднетяжмаш? Речь шла не о промышленности а о новизне — и в этом смысле метапрограммирование скорее всего старее, чем ООП.
J>>нет, изначально речь не о новизне, а о том, что это была общеизвестная базовая вещь во времена создания С++.
ГВ>Не путай два термина: "метапрограммирование" вообще и "метапрограммирование на шаблонах [C++]".
ГВ>Первому — много-много лет. Второму — сам понимаешь.
Еще раз — речь не шла о новизне. Речь шла о том, что С++ создавался в ответ на насущные потребности ("базовые вещи") тогдашних программистов, и рефлексия с метапрограммированием в списке этих базовых вещей не значились, сколько бы они не существовали к тому времени. Иначе, очевидно, либо в С++ сразу была бы добавлена поддержка рефлексии и метапрограммирования, либо популярным стал бы любой другой язык, который бы это предложил. Но людям в то время была нужна эффективная поддержка ООП, а не метапрограммирования. Поэтому ругать С++ за то, что он не имеет "базовых вещей" как они видятся из сегодняшнего дня, некорректно. Я говорил лишь и исключительно об этом.
Здравствуйте, jazzer, Вы писали:
ГВ>>А какое отношение имеет "Вау!" от "всех программистов" к истории метапрограммирования вообще и истории квазицитирования в частности?
J>Абсолютно никакого.
Правильно!
J>Это имеет отношение исключительно к упреку в адрес С++ за то, что он не имеет такой "базовой вещи" как рефлексия. Во времена создания С++ это базовой вещью ("вау" от "всех программистов") не было. Также как и исчисление бесконечно малых не было базовой вещью во времена Зенона. J>Смотри переписку с еао197, я уже устал по 10-му разу повторять.
Ёлки зелёные! Флейм на километр, ради того, чтобы вычислить апелляцию к коллективу в тезисе "рефлексия — это базовая возможность для языка программирования". Батенька, вы больше так не делайте.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ёлки зелёные! Флейм на километр, ради того, чтобы вычислить апелляцию к коллективу в тезисе "рефлексия — это базовая возможность для языка программирования". Батенька, вы больше так не делайте.
ну сам же знаешь, как это бывает
Когда отвечаешь на первые два-три сообщения — флейма еще нет и все в теме, а потом, когда ветки разрастаются, никто уже не читает, с чего все началось и привязываются к одному сообщению (и сам грешен, если вижу новый большой флейм, обычно читаю только оцененные сообщения, хотя по-хорошему, конечно же, их тоже надо читать в контексте всей дискуссии). А изначально эта тема вообще была выделена из обсуждения нового стандарта С++, темы сугубо локальной.
P.S. Мне все это напомнило известную хохму с цитатой из полн. соб. соч. В.И.Ленина.
Цитировалось следующее: "Было бы ошибкой думать". И ссылка на том, страницу, все как положено.
При этом в оригинале было: "Было бы ошибкой думать, что .....".
Вот что хорошо чувствуется в его ответах, так это огорчение от повсеместного идиотизма и деградации образования. Вот это — действительно проблема. А всё прочее — чепуха.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>С++ из 85-го. С теми концепцияи которые были хороши тогда.
Повсюду вижу эту фразу и меня удивляет следующая вещь. C++ не на пустом месте возник. Он же прямой наследник C. Собственно, именно совместимость с C обеспечила ему такую популярность. Ведь были и другие ОО-языки, так все выбрали именно C++.
Вот появились в C# 2.0 generics. А в C# 3.0 — LINQ. Из-за этого мы можем утверждать, что C# 3.0 — совсем другой язык? Или вот в C++ до определённой поры не было шаблонов. Почему же с добавлением такой значимой фичи его не переименовали в C++++?
Так вот, когда мы говорим о C++ с его проблемами, нужно помнить, что эти проблемы были заложены ещё в 70-е годы во время становления C. И C++ потому язык даже более старый, чем принято упоминать.
Здравствуйте, jazzer, Вы писали:
J>Вот если бы в С++ не было поддержки ООП — такой упрек был бы корректным. Потому что в то время было четкое понимание, что языки должны поддерживать ООП в том или ином виде.
Это уже преувеличение. Ведь именно благодаря С++ идея "все должно быть объектным и ориентированным" овладела массами.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, jazzer, Вы писали:
J>>Ну если верить этой странице (http://en.wikipedia.org/wiki/Timeline_of_programming_languages), то Ада и С++ — ровесники: 1983 год.
Т>С той разницей, что для Ады 1983 год — дата принятия стандарта, а для С++ — смены названия.
Разница была еще и в том, что Ада не была объектно-ориентированной.
И для С++ это тоже была не просто смена названия:
New features were added including virtual functions, function name and operator overloading, references, constants, user-controlled free-store memory control, improved type checking, and a new single-line comment style with two forward slashes (//).
Здравствуйте, VladD2, Вы писали: VD>Здравствуйте, Tonal-, Вы писали: T>>Чем этот код плох? VD>Тем что его очень сложно понять. А ведь это совершенно примитивный пример. Реальные грамматики куда сложее.
Понять его не сложнее, чем Вариант на Немерле
мне кажется хуже, но тирпим. VD>Твой же просто не приемлем.
Может будешь аргументировать свои высказывания, иначе получается просто трёт.
Или тебе просто так трепаться по приколу, заваливая собеседников едкими ответами подкреплёнными только гонором и спесью?
Ты даже не заметил ошибок в моём коде, которые были бы невозможны в декларативном синтаксисе.
С моей точки зрения, проблемы здесь в другом: т.к. в С++ отсутствует рантаймовское сопоставление с образцом, эмуляция почти всегда проиграет синтаксису.
Вот несколько действительных аргументов:
Не унифицированно, значит надо изобретать/изучать заново для каждого случая.
Все таки многословность — примерно в 1.5 2 раза больше писать.
Проверка синтаксиса компилятором затруднена или отсутствует.
Невозможна оптимизация компилятором.
С другой стороны, у тебя всегда есть возможность подогнать решение под задачу.
Ну и можно создать двольно общую библиотеку.
Здравствуйте, eao197, Вы писали:
E>Поверьте, если не вестись на пропаганду местных .NET евангелистов и не зачитываться экстремалами от C++ (Александреску того же), то на C++ можно писать очень даже спокойно, качественно и не напрягаясь.
Верю. Имхо, современные проблемы C++ очень хорошо изложил Маршак
Ты старомоден. Вот расплата
За то, что в моде был когда-то.
Здравствуйте, VladD2, Вы писали:
VD>>>MFC входит в комплект VC, и по сути является стандартной библиотекой. CC>>С каких пор VC стало стандартом С++ ? VD>>>WinForms стандартной библиотекой не является. Он является частной библиотекой МС. CC>>Равно как и MFC в таком случае. VD>Значит ты согласен, что вхождение библиотеки в комплект поставки продукта от МС еще не означает, что библиотека становится стандратной?
Да. Тут у нас с тобой ничья
VD>Я тебе просто продемонстрировал твои же двойные стандарты. Ведь ты не считаешь С++ непереносимым в следствии того, что у него нет стандартной библиотеки ГУИ? Ну, так почему же точно такой же факт в CLI ты склонен считать основанием для не пререносимости?
Ну, потому как ошибочно считал что WinForms входит в стандартные библиотеки.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, VladD2, Вы писали:
E>>не нужно оценивать астролябию с позиции пользователя GPS приемника.
VD>+1 Согасись, что так же глупо использовать астролябию в наше время для навигации по местности. Вот об этом люди и говорт. С++ из 85-го. С теми концепцияи которые были хороши тогда. Но используют его сейчас и с теми концепциями (плюс немного новых) что были тогда. Вот и выходит, что ты предлагаешь не говорить о том, что современные люди используют доисторические инструменты.
Я, прежде всего, предлагаю не осуждать кого-либо за использование какого-либо инструмента. И исхожу из того, что люди в большинстве своем, вполне разумны и делают осмысленный выбор на основании своих конкретных условий. Если кто-то использует C++ -- значит в его конкретных условиях это нормально и выгодно.
А развешивание ярлыков вроде "доисторических" инструментов вызывает только неприятие как самого говорящего такие вещи, так и его идей.
Тем более, что даже в наше время использование GPS приемников не всегда возможно как по техническим, так и по финансовым, так и по идеологическим причинам. Например, не может наша военка устанавливать на военную технику GPS приемники в качестве основного средства навигации -- просто из-за того, что данной системой владеет потенциальный противник. Использование секстантов для определения широты является обязательным предметом при подготовке морских штурманов (что вполне разумно, т.к. техника временами выходит из строя и GPS приемники здесь не исключение). И, если не ошибаюсь, GPS приемники бесполезны в зонах высоких помех для радиосигналов.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, konsoletyper, Вы писали:
VD>>С++ из 85-го. С теми концепцияи которые были хороши тогда.
K>Повсюду вижу эту фразу и меня удивляет следующая вещь. C++ не на пустом месте возник. Он же прямой наследник C. Собственно, именно совместимость с C обеспечила ему такую популярность.
Это, имхо, спорное утверждение. Совместимость с C оказала очень серьезное влияние на дешевизну и распространение C++ на различные платформы. Ведь, во-первых, C++ просто напросто унаследовал всю готовую стандартную библиотеку из C (хотя на тот момент она еще и не была стандартом). И, во-вторых, C++ изначально существовал как Cpre, затем как Cfront -- т.е. препроцессор, который из C++ кода генерировал C-шный код, который затем обрабатывался C-ным компилятором и линкером.
Так что разработчики C++ в то время пошли по пути, по которому сейчас идут разработчики Scala и Nemerle -- использование готовых библиотек вместо написания собственных.
Что же касается популярности C и воздействие этой популярности на популярность C++ -- это, имхо, открытый вопрос. Ведь C всегда, и в то время так же, рассматривался как низкоуровневый системный язык. А C++ проектировался как более высокоуровневый, т.е. для другой ниши, как конкурент Simula, но настолько же эффективный, как C.
K>Ведь были и другие ОО-языки, так все выбрали именно C++.
Далеко не все выбрали C++. Был еще и Smalltalk, был Object Pascal для Apple, был Objective-C, был Eiffel.
K>Вот появились в C# 2.0 generics. А в C# 3.0 — LINQ. Из-за этого мы можем утверждать, что C# 3.0 — совсем другой язык? Или вот в C++ до определённой поры не было шаблонов. Почему же с добавлением такой значимой фичи его не переименовали в C++++?
А C++ и так переименовывали, ведь он был изначально C with Classes, затем было промежуточное название C84, и лишь потом, в 1983-м появилось название C++. Причем смена названия была вызвана именно необходимостью показать, что C++ собирается идти гораздо дальше, чем C with Classes. А желание добавить в C++ шаблоны возникло у разработчиков языка еще в 1986 (если не раньше). Так что можно считать, что шаблоны и исключения были изначально запланированы в языке. Поэтому и не нужно было менять название из-за их появления.
Тут, кстати, другое интересно -- механизм шаблонов и исключений был описан для C++ в 1988-1990 годах. Но в Java generic-и добавились только в 2003-м (если я не путаю дату выхода Java 1.5). А появившаяся в 2000-м первая версия C# так же не содержала generic-ов. И это не смотря на то, что шаблоны уже десять лет до этого демонстрировали свою полезность и востребованность! Так что еще совсем недавно C++ предоставлял разработчикам такие языковые возможности, которых не было у его конкурентов. Тем более, что даже в 2000-м и 2001-м у той же Java производительность ни шла ни в какое сравнение с производительностью C++.
K>Так вот, когда мы говорим о C++ с его проблемами, нужно помнить, что эти проблемы были заложены ещё в 70-е годы во время становления C. И C++ потому язык даже более старый, чем принято упоминать.
Если даже не брать историю C, то сам по себе C++ намного старше. Поскольку работы над C with Classes Страуструп начал в 1979-1980, а в 1980-м году первый Cpre был даже использован в реальном проекте (по воспоминаниям Страуструпа).
Вообще же, для понимания идей и пути развития C++ очень рекомендую прочитать "Дизайн и эволюция языка C++". Особенно первые главы -- отношение я языку меняется значительно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Hello, Cyberax!
You wrote on Wed, 31 Jan 2007 22:39:08 GMT:
C>>> Gen. GC в Java весьма сложно отключить >> Сорри, incremental GC хотел написать. C> Его как раз отключать не надо, так как он сильно помогает C> уменьшить частоту полных сборок.
Разве я писал что его нужно отключать?
Меняем generational на incremental:
Если причиной тому был большой размер кучи, то возможно проблема решалась бы включением incremental GC и соответствующей настройкой размера young/old generations.
C>>> Механизм HotSpot напрямую к GC не относится. >> Не совсем понял. Разве то, что понимается под HotSpot не включает >> в себя generational GC? C> HotSpot — это механизм перекомпиляции кода "на лету", по C> результатам профилирования.
The Java HotSpot Virtual Machine is Sun's VM for the Java platform. It delivers the optimal performance for Java applications using many advanced techniques, incorporating a state-of-the-art memory model, garbage collector, and adaptive optimizer. It is written in a high-level, object-oriented style, and features:
— Uniform object modelInterpreted, compiled, and native frames all use the same stack
— Preemptive multithreading based on native threads
— Accurate generational and compacting garbage collection
— Ultra-fast thread synchronization
— Dynamic deoptimization and aggressive compiler optimizations
— System-specific runtime routines generated at VM startup time
— Compiler interface supporting parallel compilations
— Run-time profiling focuses compilation effort only on "hot" methods
Скорее всего, проблема в том, что ты понимаешь под HotSpot механизм JIT-компиляции, а я имел в виду HotSpot VM. Строго говоря, наверное их стоит различать, хотя как ты сам видишь, даже в документах от Sun этого не делается: часто под HotSpot понимается VM полностью.
C> Непосредственно к GC он отношения не имеет, в JRE от SUN есть C> несколько независимых алгоритмов GC.
Разумеется есть различные алгоритмы, только все они основываются на модели поколений. Это базовый подход к сборке мусора в HotSpot (HotSpot VM).
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, dr.Chaos, Вы писали:
DC>>Мощный — это как?
K>Это так, как мы себе и прдставить не можем. Вот рассказал бы кто-то про нынешние 3D-игры лет 20 назад, его бы психом посчитали.
Хм. Однако . Слышу звон, но не знаю где он.
DC>>ИМХО С++ довольно неплохо подходит для создания графических движков, это одна из тех задач, откуда его будет очень не просто вытеснить .
K>Да на ассемблере тоже можно неплохой движок написать.
Напиши . Я хочу на это посмотреть . Видел демки 200-300Кб с нормально 3D графикой и музыкой, но это не движок
K>Просто сейчас C++ — это лучшее, что подходит для данной задачи. Но надо понимать, что это не навсегда.
Да именно лучшее, на это есть объективные причины. Сам Страуструп никогда не считал C++ лучшим из языков, он просто его называет достаточно хорошим для решения практически любой задачи.
Мало того он признает что для прикладного программирования С++ не очень хорошо подходит именно из-за отсутствия GC и плохой компонентной модели.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Мощный — это как?
VD>Мощьный — это значит фунциональный, удобный надежный и в меру быстрый.
DC>>ИМХО С++ довольно неплохо подходит для создания графических движков, это одна из тех задач, откуда его будет очень не просто вытеснить .
VD>Это заблуждение. С++ уже ни для чего кроме возни с битами не подходит хорошо.
Что именно? То что неплохо подходит или то что непросто вытеснить? Хм, а графический движок не с битами возиться? Или я чего-то недопонимаю?
VD>Тут как-то пробегала ссылка на презентацию ролов создающих (если не ошибаюсь) новый Анрлиэл. Там как раз говорилось, что С++ не удоволетворяет современных потребностей и что нужен новый язык. Описывлись требования к этому новому языку. И что забавно большинство из этих требований удивительно пересекались с Немерле.
VD>Обсуждение с ходу не нашел, но нашел ссылку на презентаху: VD>http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt VD>Вот мнение о С++ из нее: VD>
Reliability
VD>Error-prone language / type system leads to wasted effort finding trivial bugs
VD>Significantly impacts productivity
VD>Concurrency
VD>Hardware supports 6-8 threads
VD>C++ is ill-equipped for concurrency
Дык я и не утверждал что инструмент лучший. Но только на данный момент есть только требования к новому языку, но языка то еще нет. Так что мимо кассы, как появиться инструмент так и говорить можно будет.
Полагаю что новый стандарт решит часть проблем в С++.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, konsoletyper, Вы писали: K>Или вот в C++ до определённой поры не было шаблонов. Почему же с добавлением такой значимой фичи его не переименовали в C++++?
Потому что С++ — это не lvalue, соответственно, (С++)++ не скомпилируеться
[]
VD>Ну, нормальный человек и так прочесть может . Здесь очевидно разбирается некий язык токены которого лежат в списке decls.
ну ты никогда не можешь удержаться, чтобы не попытаться унизить собеседника. Оказывается большинство программистов уже просто обязаны "читать" немерле, дожили...
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
КЛ>>Люди, но неужели вы до сих пор не поняли, что на с# нельзя писать программы с нетривиальной логикой просто потому, что он для этого не предназначен? Он просто убог для этого. КЛ>>Simple data flow — да, но не больше.
КЛ>>Одно отсутствие const параметров методов — это убийство.
КЛ>>Я это говорю, исходя из личного опыта. У меня "эйфория" от него прошла довольно быстро.
VD>Как ты думаешь, чего стоит твой опыт после таких заявлений?
чего стоит мой — я знаю. А вот чего стоит твой? Кроме шапкозакидательства, хамства, снобизма, и т.п. пока ничего толкового не увидел.
На днях планирую посмотреть подробнее на немерле и написать о впечатлениях.
Здравствуйте, Cyberax, Вы писали:
C>Андрей Хропов wrote: >> C>Это не сильно больше, чем в новом Стандарте С++. >> В каком? который 0x? Так он еще когда выйдет. C>Через два года.
Это они только
expressed a strong desire
.
C>Следующий ISO-стандарт для C# тоже еще не близко.
Так то, что я привел, уже стандарт и уже реализовано в MS.NET и Mono.
C>Ну это точно такая же ситуация, как и с С++. Необходимо будет C>тестировать на совместимость со всеми средами так же, как и в случае с C>С++ требуется тестировать с разными компиляторами.
Если у тебя портабельная библиотека, то это требует минимальных усилий (ну как с Java ситуация).
C>Ну так и в C# точно так же, используешь какой-нибудь системно-зависимый C> контрол — и привет портируемости.
Ну естественно. Но это уж, что называется, сам виноват.
>> Стандарт должен обеспечивать возможность простой интеграции библиотек и >> базовую функциональность. Все остальное — в портабельные библиотеки. C>Если нет стандарта на библиотеки — то будет зоопарк (собственно, он УЖЕ C>есть).
Стандартная библиотека не может охватывать все области человеческой деятельности. В ней должен быть необходимый минимум для интероперабельности.
Вот, например, возьмем тот же GUI. Каким он должен быть — на нативных контролах или одинаковый на всех платформах? Иконки растровые или векторные? Должен смену скинов поддерживать или нет? Слишком много разных требований, на всех не угодишь.
C>Вот в Java, фактически, такой стандарт есть — это Sun JDK, который есть C>на куче платформ. А сейчас вообще открытым стал.
Да, ну так там тоже зоопарк. GUI на чем делать — на AWT или Swing?
MS заинтересована прежде всего в поддержке своей платформы поэтому они более высокие уровни (ASP.NET, ADO.NET, WinForms, WWF, WCF, WPF) не вносят в стандарт. Но в Mono первые 3 почти доделали их для совместимости, а также предлагают и свои портабельные альтернативы (тот же Gtk#).
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, Константин Л., Вы писали:
КЛ>>Люди, но неужели вы до сих пор не поняли, что на с# нельзя писать программы с нетривиальной логикой просто потому, что он для этого не предназначен? АХ>А где в предыдущем сообщении VladD2 говорил про C#?
это не важно. Зуб даю, что до появления немерле он с таким же смаком ломал людям кайф и в неподходящих местах ругал с++ и хвалил c#. У него жизненное кредо такое, наверное.
КЛ>> Он просто убог для этого. АХ> Программы с нетривиальной логикой можно писать на любом Тьюринг-полном языке. На C, который прост как табуретка, вон Oracle всякие написаны.
КЛ>>Одно отсутствие const параметров методов — это убийство. АХ>Ну соглашусь, что это недостаток.
это огромнейший недостаток. const это не только способ документирования кода, но и способ избавления от многих ошибок. В c# каждый метод — черный ящик. Что он может сделать с твоим объектом можно только догадываться.
А как тебе читабельность?
1) отмена :: есть большая ошибка.
2) возможность называть переменные, свойства и т.п. так же, как и типы — еще одна ошибка.
АХ>С другой стороны и у C++ много косяков. Как насчет отсутствия override?
ерунда.
АХ>Также можно сказать, что так как в C++ нет GС, то писать на нем — это убийство .
отсутствие GC — самое последнее, что заботит с++ программера. Конечно приходится "достраивать", используя smart pointers etc., но это настолько просто, что это даже не обсуждается. И это дает возможность выбора.
АХ>Вообще для меня нет пока идеального языка.
K>>Да на ассемблере тоже можно неплохой движок написать. DC>Напиши . Я хочу на это посмотреть . Видел демки 200-300Кб с нормально 3D графикой и музыкой, но это не движок
Такие демки даже intro 64 практически все написаны на Си или C++
Здравствуйте, VladD2, Вы писали:
DC>>ИМХО С++ довольно неплохо подходит для создания графических движков, это одна из тех задач, откуда его будет очень не просто вытеснить .
VD>Это заблуждение. С++ уже ни для чего кроме возни с битами не подходит хорошо.
VD>Тут как-то пробегала ссылка на презентацию ролов создающих (если не ошибаюсь) новый Анрлиэл. Там как раз говорилось, что С++ не удоволетворяет современных потребностей и что нужен новый язык. Описывлись требования к этому новому языку. И что забавно большинство из этих требований удивительно пересекались с Немерле.
Там говорилось не про язык для создания движков а про язык для прикладного кода игры.
Здравствуйте, Константин Л., Вы писали:
КЛ>это огромнейший недостаток. const это не только способ документирования кода, но и способ избавления от многих ошибок. В c# каждый метод — черный ящик. Что он может сделать с твоим объектом можно только догадываться.
Про const_cast расказывать надо?
КЛ>А как тебе читабельность?
Гораздо лучше чем в С++
КЛ>1) отмена :: есть большая ошибка. КЛ>2) возможность называть переменные, свойства и т.п. так же, как и типы — еще одна ошибка.
Обоснований конечно не будет.
АХ>>С другой стороны и у C++ много косяков. Как насчет отсутствия override? КЛ>ерунда.
Ой не скажи...
КЛ>отсутствие GC — самое последнее, что заботит с++ программера.
И кто тут занимается шапкозакидательством?
КЛ>Конечно приходится "достраивать", используя smart pointers etc., но это настолько просто, что это даже не обсуждается. И это дает возможность выбора.
А ты знаешь что для того чтобы реализовать эти самые smart pointers нужен счетчик ссылок. А то что счетчик ссылок не работает в присутствии циклических связей что приводит к тому что нужно кувалдой расправлять простую и понятную систему с циклическими связями в дерево?
А то что в многопоточной среде для него необходимы как минимум Interlocked функции которые в многопроцессорных системах очень дороги?
А ты знаешь что банальные new/delete в многопоточной среде каждый раз лочатся? Хоть эти локи и можно иногда оптимизировать при помощи страшных платформозависимых вывертов но также просто и эффективно как ГЦ всеравно работать не будет. А если ГЦ еще и region inference поможет то плюсовый хип вобще будет в пролете.
АХ>>Вообще для меня нет пока идеального языка. КЛ>а его и не будет, наверное )
А разве это не С++?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, dr.Chaos, Вы писали:
K>>>Да на ассемблере тоже можно неплохой движок написать. DC>>Напиши . Я хочу на это посмотреть . Видел демки 200-300Кб с нормально 3D графикой и музыкой, но это не движок
FR>Такие демки даже intro 64 практически все написаны на Си или C++
Вполне возможно . Я их не писал .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, WolfHound, Вы писали:
WH>А то что в многопоточной среде для него необходимы как минимум Interlocked функции которые в многопроцессорных системах очень дороги?
Да ну? lock xadd dword ptr [ecx],eax не такая дорогая инструкция.
WH>А ты знаешь что банальные new/delete в многопоточной среде каждый раз лочатся? Хоть эти локи и можно иногда оптимизировать при помощи страшных платформозависимых вывертов но также просто и эффективно как ГЦ всеравно работать не будет.
Пардон, а выделение памяти из разных потоков в условиях GC как отрабатывает? Разве лок при этом не нужен?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Plague, Вы писали:
VD>>У Оберона вроде как ЖЦ убитый. Если только заменить... P>А что у него с GC? можно где-нить почитать?
У него поколений нет. И инкрементально собирать мусор тоже не умеет.
Те если есть миллион фоновых объектов то тушите свет...
Это если конечно с последнего флейма ничего не изменилось(что врятли).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Константин Л., Вы писали:
КЛ>>это огромнейший недостаток. const это не только способ документирования кода, но и способ избавления от многих ошибок. В c# каждый метод — черный ящик. Что он может сделать с твоим объектом можно только догадываться. WH>Про const_cast расказывать надо?
ой и плохо же ты обо мне думаешь. Согласись, что допустить ошибку с пом. const_cast гораздо тяжелее, тк его надо *написать*. Те человек сознательно это делает. Разницу улавливаешь?
КЛ>>А как тебе читабельность? WH>Гораздо лучше чем в С++
КЛ>>1) отмена :: есть большая ошибка. КЛ>>2) возможность называть переменные, свойства и т.п. так же, как и типы — еще одна ошибка. WH>Обоснований конечно не будет.
будут. Не понятно, что зовется. То-ли инстанс-метод, то-ли статический.
про 2), думаю, объяснять не нужно.
АХ>>>С другой стороны и у C++ много косяков. Как насчет отсутствия override? КЛ>>ерунда. WH>Ой не скажи...
ой скажу
КЛ>>отсутствие GC — самое последнее, что заботит с++ программера. WH>И кто тут занимается шапкозакидательством?
ну меня не заботит. Спроси 100 квалифицированных с++ программеров, и 95 скажут, что не заботит.
КЛ>>Конечно приходится "достраивать", используя smart pointers etc., но это настолько просто, что это даже не обсуждается. И это дает возможность выбора. WH>А ты знаешь что для того чтобы реализовать эти самые smart pointers нужен счетчик ссылок. А то что счетчик ссылок не работает в присутствии циклических связей что приводит к тому что нужно кувалдой расправлять простую и понятную систему с циклическими связями в дерево?
конечно не знаю, я знаю только new
С циклическими связями косяк, но и он разрешим.
WH>А то что в многопоточной среде для него необходимы как минимум Interlocked функции которые в многопроцессорных системах очень дороги?
хм. Да. Но даже при этом это будет капля в море по сравн. с издержками .net.
WH>А ты знаешь что банальные new/delete в многопоточной среде каждый раз лочатся? Хоть эти локи и можно иногда оптимизировать при помощи страшных платформозависимых вывертов но также просто и эффективно как ГЦ всеравно работать не будет. А если ГЦ еще и region inference поможет то плюсовый хип вобще будет в пролете.
да ничего я не знаю, я улицы подметаю обычно. Вот комп первый раз показали, я и решил тут поважничать.
Хм...А в .net не так? Может быть быстрее, но в итоге все равно lock
АХ>>>Вообще для меня нет пока идеального языка. КЛ>>а его и не будет, наверное ) WH>А разве это не С++?
Здравствуйте, CreatorCray, Вы писали:
WH>>А то что в многопоточной среде для него необходимы как минимум Interlocked функции которые в многопроцессорных системах очень дороги? CC>Да ну? lock xadd dword ptr [ecx],eax не такая дорогая инструкция.
Пока у тебя один процессор...
CC>Пардон, а выделение памяти из разных потоков в условиях GC как отрабатывает? Разве лок при этом не нужен?
Там очень легко делается по куче на процессор.
Далие делаем синхронную сборку мусора...
И чем глубже в систему это интегрируешь тем лучше это будет работать.
Например если сделать ОС полностью управляемой то никто не мешает просто запрещать прирывания на данном процессоре во время выделения памяти.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, CreatorCray, Вы писали:
CC>Пардон, а выделение памяти из разных потоков в условиях GC как отрабатывает? Разве лок при этом не нужен?
Полностью остонавливает все потоки на некторых стадиях сборки
И для C++ и для разных вариантов GC есть неблокирующие или малоблокирующие распределители памяти, так что подавать это как преимущество GC неккоректно.
Здравствуйте, FR, Вы писали:
FR>Полностью остонавливает все потоки на некторых стадиях сборки
А в С++ память освобождать не нужно?
FR>И для C++ и для разных вариантов GC есть неблокирующие или малоблокирующие распределители памяти, так что подавать это как преимущество GC неккоректно.
Нука покажи мне реализацию неблокирующего менеджера памяти для С++.
Только смотри я его на четырехроцессорной машине запущу...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, FR, Вы писали:
FR>>Полностью остонавливает все потоки на некторых стадиях сборки WH>А в С++ память освобождать не нужно?
Нет конечно
FR>>И для C++ и для разных вариантов GC есть неблокирующие или малоблокирующие распределители памяти, так что подавать это как преимущество GC неккоректно.
WH>Нука покажи мне реализацию неблокирующего менеджера памяти для С++.
А ты покажи полностью неблокирующий GC.
WH>Только смотри я его на четырехроцессорной машине запущу...
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, CreatorCray, Вы писали:
WH>>>А то что в многопоточной среде для него необходимы как минимум Interlocked функции которые в многопроцессорных системах очень дороги? CC>>Да ну? lock xadd dword ptr [ecx],eax не такая дорогая инструкция. WH>Пока у тебя один процессор...
Теперь скорее не на многопроцессорность а на многоядерность упор. На двух ядрах — полет нормальный.
WH>Там очень легко делается по куче на процессор.
Грубо говоря по куче на поток. Это можно и без GC. WH>Далие делаем синхронную сборку мусора...
Т.е. останавливаем на этот момент вообще все потоки.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
VD>>Значит ты согласен, что вхождение библиотеки в комплект поставки продукта от МС еще не означает, что библиотека становится стандратной? CC>Да. Тут у нас с тобой ничья
У нас нет ничьей. Просто я поставил тебя на место тех кто с тобой пытается дискутировать. Теперь ты сам видишь неверность своих посылок.
CC>Ну, потому как ошибочно считал что WinForms входит в стандартные библиотеки.
Тогда и MFC входит. Стандарт показать конечно не смогу, так как это стандарт де-факто являющися таковым только для тех кто использует MFC.
Так что ты уж определись.
Или не переносимы и C++ и CLI-сборки, так как у них у обоих нет стандартного ГУИ. Или тебе прийдется признать, что переносимо и то и другое и и то и другое для переносимости требует тщательного выбора используемых библиотек. Так если хочешь не иметь проблем с ГУИ в переносимом приложении, то прийдется использовать GTK.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Сильно сложее. Я знаю оба языка, но в твоем варианте разобраться с ходу не могу. Немерловый же я читаю потчи так же легко как грамматику.
То что ты не хочешь признать очевидных вещей выдает в тебе остуствие конструктивизма. Общаться при этом смысла нет.
T>Может будешь аргументировать свои высказывания, иначе получается просто трёт.
А что тут аргументировать? Сравин объем кода. Сравни количество неинформативной грязи. Сравни схожесть с исходной грамматикой.
T>Или тебе просто так трепаться по приколу, заваливая собеседников едкими ответами подкреплёнными только гонором и спесью?
У собеседников проблемы даже не с гонором и спесью. У них проблемы с банальной адекватностью.
ОК можно попытаться вырзить все в цифрах. Итак:
* Исходная грамматика содержит 81 символ без пробелов.
* Вариант Вольфхаунда 372 символа без пробелов.
* Твой вариант 653 символа без пробелов.
При этом исходная грамматика не содержит семантики в отличии от двух других вариантов. За счет нее можно дать исходной грамматике 100% гандикапа. И того идеальным размером парсера был бы ~160 символов. Вольфхаунд превысил этот показатель более чем в двое, ты более чем в 4 раза.
Еще что-то доказывать надо?
При этом твой код это еще к тому же и банальное машейничество. Ведь самого распознования тут нет. Тут присуствует вызов каких-то функций которые по видимости должны заниматься распознованием токенов. Прибавь этот код и он уже будет ужасно огромным.
T>Ты даже не заметил ошибок в моём коде, которые были бы невозможны в декларативном синтаксисе.
А что их замечать? Код ужасен и без этого.
T>Ну и можно создать двольно общую библиотеку.
В Бусте есть Спирит. Что-то он сильно проигрывает по гибкости встроенному сопсоставлению с образцом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
VD>>Ну, нормальный человек и так прочесть может . Здесь очевидно разбирается некий язык токены которого лежат в списке decls.
КЛ>ну ты никогда не можешь удержаться, чтобы не попытаться унизить собеседника.
Что-ты, что-ты? Собеседник унижает сбея сам.
КЛ>Оказывается большинство программистов уже просто обязаны "читать" немерле, дожили...
Нет, нет. Только нормальные программисты которые не хотят оставаться в рамках одной идеологии.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
хм...По-моему тут унижает себя сам только один человек, и это не я. Задумайся над этим. Ты у меня уже давно потерял уважение. Думаю не только у меня. Ну это уже твои проблемы.
Здравствуйте, jazzer, Вы писали:
J>Разница была еще и в том, что Ада не была объектно-ориентированной.
А вот это смотря что считать ООП. В Аде 83 года не было tagged types. Это что-то вроде virtual в C++. Причём не сказать, что в Аде вообще не было ООП. Были инкапсуляция, наследование. А с полиморфизмом разобрались только к 95 (точно не знаю, но видимо до этого его реализовывали обходными путями). При этом в стандарте 83 года уже были generics.
Здравствуйте, dr.Chaos, Вы писали:
DC>>>ИМХО С++ довольно неплохо подходит для создания графических движков, это одна из тех задач, откуда его будет очень не просто вытеснить .
K>>Да на ассемблере тоже можно неплохой движок написать. DC>Напиши . Я хочу на это посмотреть . Видел демки 200-300Кб с нормально 3D графикой и музыкой, но это не движок
Да ладно, не вопрос. Только мне понадобится $2'000'000'000 и 10 лет.
Здравствуйте, Константин Л., Вы писали:
КЛ>это огромнейший недостаток. const это не только способ документирования кода, но и способ избавления от многих ошибок. В c# каждый метод — черный ящик. Что он может сделать с твоим объектом можно только догадываться.
Передавай объекты через интерфейсы с немутирующими методами, и будет тебе щастье!
WolfHound wrote: > FR>И для C++ и для разных вариантов GC есть неблокирующие или > малоблокирующие распределители памяти, так что подавать это как > преимущество GC неккоректно. > Нука покажи мне реализацию неблокирующего менеджера памяти для С++. > Только смотри я его на четырехроцессорной машине запущу...
Hoard (http://www.hoard.org/) лично наблюдал на 8-процессорном сервере
Здравствуйте, CreatorCray, Вы писали:
WH>>Пока у тебя один процессор... CC>Теперь скорее не на многопроцессорность а на многоядерность упор. На двух ядрах — полет нормальный.
Куда теперь упор это вопрос весьма спорный. В конторе где я работаю есть машинки с четырьмя двуядерными процессорами...
WH>>Там очень легко делается по куче на процессор. CC>Грубо говоря по куче на поток.
Нет. Кучу нужно вешать на процессор. Ибо например у меня есть сервачек в котором потоки исчисляются сотнями тысяч...
CC>Это можно и без GC.
Очень сложно. Есть проблемы с удалением объектов созданных в другом потоке.
WH>>Далие делаем синхронную сборку мусора... CC>Т.е. останавливаем на этот момент вообще все потоки.
Что лучше один раз тормознуть и прибраться или постоянно лочить шину на каждый чих?
В любом случае оптимизация менеджера памяти не снимает проблему счетчиков ссылок.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, FR, Вы писали:
WH>>Нука покажи мне реализацию неблокирующего менеджера памяти для С++. FR>А ты покажи полностью неблокирующий GC.
Колличество локов сравни...
WH>>Только смотри я его на четырехроцессорной машине запущу... FR>Тут http://www.garret.ru/~knizhnik/threadalloc/readme.html принцип, тот же кстати что и в некторых моделях GC используется. Искать ссылки на конкретные библиотеки сейчас некогда.
Тупой алгоритм. У меня лучше.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, Константин Л., Вы писали:
КЛ>>это огромнейший недостаток. const это не только способ документирования кода, но и способ избавления от многих ошибок. В c# каждый метод — черный ящик. Что он может сделать с твоим объектом можно только догадываться.
K>Передавай объекты через интерфейсы с немутирующими методами, и будет тебе щастье!
Здравствуйте, Константин Л., Вы писали:
K>>Передавай объекты через интерфейсы с немутирующими методами, и будет тебе щастье! КЛ>шутишь?
А что по товоему методы с модификатором const как не описание интерфейса объекта с немутирующиме методами?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
>> Только смотри я его на четырехроцессорной машине запущу... C>Hoard (http://www.hoard.org/) лично наблюдал на 8-процессорном сервере
Это наверное глупость но я без крайней нужды не пользуюсь кодом в котором смешаны табы и пробелы.
Ну не верю я в то что человек небрежный в таких мелочах может сделать что-то что работает хорошо.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: >> > Только смотри я его на четырехроцессорной машине запущу... > C>Hoard (http://www.hoard.org/) лично наблюдал на 8-процессорном сервере > Это наверное глупость но я без крайней нужды не пользуюсь кодом в > котором смешаны табы и пробелы. > Ну не верю я в то что человек небрежный в таких мелочах может сделать > что-то что работает хорошо.
А ты не смотри — просто подлинкуй его, он у нас работал без каких-либо
проблем ВООБЩЕ. Мы его в итоге даже купили.
Здравствуйте, Cyberax, Вы писали:
C>А ты не смотри — просто подлинкуй его, он у нас работал без каких-либо проблем ВООБЩЕ. Мы его в итоге даже купили.
Я так не могу.
Я перед новым годом уже выловил квадратичный алгоритм в стороннем коде который вобще без проблем работал два года пока туда приходило по 10-30 байт. Но когда пришлось обходить ограничение другой поделки пришлось туда загнать 100К данных. И вот тут то все и всплыло.
Заменили алгоритм на линейный и все сразу начало летать.
Так что я лучше буду читать исходники перед тем как их использовать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>А ты не смотри — просто подлинкуй его, он у нас работал без каких-либо > проблем *ВООБЩЕ*. Мы его в итоге даже купили. > Я так не могу. > Я перед новым годом уже выловил квадратичный алгоритм в стороннем коде > который вобще без проблем работал два года пока туда приходило по 10-30 > байт. Но когда пришлось обходить ограничение другой поделки пришлось > туда загнать 100К данных. И вот тут то все и всплыло. > Заменили алгоритм на линейный и все сразу начало летать.
Ну так сломается — тогда и можно смотреть. Ну и заранее потестить на
нагрузке, естественно.
> Так что я лучше буду читать исходники перед тем как их использовать.
Я тоже предпочитаю делать RTFS перед использованием. Поэтому я и не
люблю продукты MS.
Андрей Хропов wrote: > C>Через два года. > Это они только > expressed a strong desire
Ну остается только надеятся
> C>Следующий ISO-стандарт для C# тоже еще не близко. > Так то, что я привел, уже стандарт и уже реализовано в MS.NET и Mono.
Оно де-факто есть и в С++ почти везде. Только вот в реальных
невычислительных программах нужно еще кучу всего.
> C>Ну это точно такая же ситуация, как и с С++. Необходимо будет > C>тестировать на совместимость со всеми средами так же, как и в случае с > C>С++ требуется тестировать с разными компиляторами. > Если у тебя портабельная библиотека, то это требует минимальных усилий > (ну как с Java ситуация).
С Java ситуация почти идеальная, фактически, есть только одна JDK на
куче платформ. Остальные на нее ориентируются и обычно достаточно
совместимы.
> C>Ну так и в C# точно так же, используешь какой-нибудь системно-зависимый > C> контрол — и привет портируемости. > Ну естественно. Но это уж, что называется, сам виноват.
Так вот, MS делает такие ляпы ну уж ОЧЕНЬ легкими.
> Вот, например, возьмем тот же GUI. Каким он должен быть — на нативных > контролах или одинаковый на всех платформах? Иконки растровые или > векторные? Должен смену скинов поддерживать или нет? Слишком много > разных требований, на всех не угодишь.
Swing в Java Может использовать свои скины или эмуляцию родного GUI
для платформы. Работает достаточно прилично.
> C>Вот в Java, фактически, такой стандарт есть — это Sun JDK, который есть > C>на куче платформ. А сейчас вообще открытым стал. > Да, ну так там тоже зоопарк. GUI на чем делать — на AWT или Swing?
AWT? Это что такое?
Сейчас есть два фреймворка — Swing и SWT. SWT — обертка над нативным API.
. VD>Сильно сложее. Я знаю оба языка, но в твоем варианте разобраться с ходу не могу. Немерловый же я читаю потчи так же легко как грамматику.
То что ты не смог разобраться может говорить о чём уггодно — например и не пытался, или о том, что свои ты знания несколько преувеличиваешь.
Я тоже не мог разобраться в варианте Немерле, пока ты не привёл грамматику.
VD>То что ты не хочешь признать очевидных вещей выдает в тебе остуствие конструктивизма. Общаться при этом смысла нет.
И чего я не хочу признавать? Резолюций от VladD2:
Код ужасен и без этого.
— мне они по барабану.
T>>Может будешь аргументировать свои высказывания, иначе получается просто трёт. VD>А что тут аргументировать? Сравин объем кода. Сравни количество неинформативной грязи. Сравни схожесть с исходной грамматикой.
Выделенное простим как непроизвольную неинформативную грязь. VD>ОК можно попытаться вырзить все в цифрах. Итак: VD>* Исходная грамматика содержит 81 символ без пробелов. VD>* Вариант Вольфхаунда 372 символа без пробелов. VD>* Твой вариант 653 символа без пробелов.
VD>При этом исходная грамматика не содержит семантики в отличии от двух других вариантов. За счет нее можно дать исходной грамматике 100% гандикапа. И того идеальным размером парсера был бы ~160 символов. Вольфхаунд превысил этот показатель более чем в двое, ты более чем в 4 раза. VD>Еще что-то доказывать надо?
И что это доказывает? То что мой код в 2 раза больше немерловского и так сразу видно.
Если перевести это на J — оно, вполне возможно сильно меньше получиться.
Без пробелов, табуляций и прочих переводов строк не один из этих вариантов читаться не будет никак.
Если нарисовать эту грамматику кисточкой — символов почти не будет, зато читаться будет великолепно, а вот вычисляться — опять таки никак.
Кстати, про объем — код я нарисовал пока пытался разобраться в исходном — т.е это просто "подстрочник" с немерля на С++. Если нужно будет реально работать в этой области, код будет меньше по крайней мере на 1/4 без потери наглядности.
Хотя, если всё-таки реально работать, то лучше честный генератор LL чем показанный рекурсивный спуск.
VD>При этом твой код это еще к тому же и банальное машейничество. Ведь самого распознования тут нет. Тут присуствует вызов каких-то функций которые по видимости должны заниматься распознованием токенов. Прибавь этот код и он уже будет ужасно огромным.
Я не знаю Немерл, и предположил, что символы Identifier, Round, Semicolon, Brace, а так же parseMessage и parseState — это не ключевые слова языка, а нечто определённое пользователем. Вот и заменил на как мне кажеться, соответствующие конструкты С++.
Т.е. Identifier, Round, Semicolon, Brace — классы а parseMessage и parseState — свободные функции. Semicolon наверное в немерле простая константа, но т.к. всё таки эмуляция сопоставления, пришлось и её сделать классом, правда довольно простым и легко параметризуемым.
Если я прав, то мой код не более мошенничество чем немерлевский — ведь к ниму тоже не прилагается определения этих символов.
А вот что ты понимаешь под самим распознаванием каюсь, не понял.
И там и здесь проверяется соответствие входной последовательности определённому шаблону. При совпадении выполняються некоторые вычисления, и рекурсивно вызывается та же функция разбора.
T>>Ну и можно создать довольно общую библиотеку. VD>В Бусте есть Спирит. Что-то он сильно проигрывает по гибкости встроенному сопоставлению с образцом.
Я как бы в курсе.
Кстати, если уж сопоставлять Спирит с сопоставлением, то какой класс грамматик поддерживает сопоставление в Немерле?
Я согласен, что декларативный синтаксис, в частности сопоставление с образцом и списковые дополнения в сочетании со статической типизацией и автоматическим выводом типов очень удобные и мощные языковые механизмы. С их помощью многие вещи можно записать более выразительно.
Но от того, что язык их содержит, он не становится автоматически лучшем_языком_в_мире_на_котором_невозможно_писать_неправильные_программы,
и наоборот, не имеющий этих наворотов язык не становиться от этого полным_отстоем, как это можно заключить по твоим высказываниям.
Читая твои посты, создаётся впечатление, что мы не в форуме "философия программирования" а на митинге в поддержку .Net + ХХХ и заклеймению непохожих.
Если тебе платят за это — скажи, я наверно пойму. (с) Б.Г.
Здравствуйте, eao197, Вы писали:
E>Я, прежде всего, предлагаю не осуждать кого-либо за использование какого-либо инструмента.
Согласен. Осуждать в данном случае не размуно. Надо просто смеяться, как смеемся мы глядя на то как кто-то попытается забить гвоздь каменным молотком.
E> И исхожу из того, что люди в большинстве своем, вполне разумны и делают осмысленный выбор
Идиалист, блин. Если бы это было так, то в 30-ых годах просшого века к власти не пришел бы Гитлер в Германии, в 90-ых Ельцин в России, а в 21 веке уже никто бы не писал на С++.
E> на основании своих конкретных условий. Если кто-то использует C++ -- значит в его конкретных условиях это нормально и выгодно.
Или он попросту поддался настроению толпы.
E>А развешивание ярлыков вроде "доисторических" инструментов вызывает только неприятие как самого говорящего такие вещи, так и его идей.
Дык не развешивай. Я выражаю свое мнение. В 21 веке С++ не место. Это динозавро который забыл вымереть.
E>Тем более, что даже в наше время использование GPS приемников не всегда возможно как по техническим, так и по финансовым, так и по идеологическим причинам.
Дык в области программирования технические и финансовые условия не работают. А вот идеологические конечно сильно влияют. Религия и фанатизм вещь суровая. Тут уж ничего не поделаеть.
E> Например, не может наша военка устанавливать на военную технику GPS приемники в качестве основного средства навигации
Да, да, это замечательное оправдание использование астролябии для запуска болистических ракет. А уж какое это оправдание для использования оной в народном хазяйсвте. О том как это влияет на С++ и его использовние вообще лучше умолчать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plague, Вы писали:
P>Здравствуйте, VladD2, Вы писали: VD>>У Оберона вроде как ЖЦ убитый. Если только заменить...
P>А что у него с GC? можно где-нить почитать?
А ничего. Используется один из примитивнеших алгоритмов. На простых тестах довольно шустро, но в реальных условиях практически не применимо. Тут где-то рядом кто-то делал тест (после пиара Губановым крутости ЖЦ Оберона), так там Оберон умер после создания нного количества объектов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Что именно? То что неплохо подходит или то что непросто вытеснить? Хм, а графический движок не с битами возиться? Или я чего-то недопонимаю?
Нет, не с битами. Они уже давно такой фигней не страдают. Почитай внимательно призентацию. Там есть про это не мало слов. На ассемблере они уже ничего не пишут. Все вычисления хотят сделать фукнциональными, чтобы ошибок по меньше было, и чтобы параллелились они хорошо.
Графика давно живет в разных дитеркиксах и шейдерах.
DC>Дык я и не утверждал что инструмент лучший. Но только на данный момент есть только требования к новому языку, но языка то еще нет. Так что мимо кассы, как появиться инструмент так и говорить можно будет.
В общем-то ОКамл или Немерле удовлетворяют большинству указанных там требований. Не всем конечно, но уж точно они в сто раз ближе к тому идеалу чем С++.
Собственно весь разговор о том, что ищется замена С++.
DC>Полагаю что новый стандарт решит часть проблем в С++.
Ни одной!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
КЛ>чего стоит мой — я знаю. А вот чего стоит твой? Кроме шапкозакидательства, хамства, снобизма, и т.п. пока ничего толкового не увидел.
Большое видится на растоянии.
КЛ>На днях планирую посмотреть подробнее на немерле и написать о впечатлениях.
Давай. Здоровый юмор никогда не бывает лишним.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Константин Л., Вы писали:
K>>>Передавай объекты через интерфейсы с немутирующими методами, и будет тебе щастье! КЛ>>шутишь? WH>А что по товоему методы с модификатором const как не описание интерфейса объекта с немутирующиме методами?
Здравствуйте, VladD2, Вы писали:
P>>А что у него с GC? можно где-нить почитать?
VD>А ничего. Используется один из примитивнеших алгоритмов. На простых тестах довольно шустро, но в реальных условиях практически не применимо. Тут где-то рядом кто-то делал тест (после пиара Губановым крутости ЖЦ Оберона), так там Оберон умер после создания нного количества объектов.
Все рассуждения поскипаны, так как дискуссия у нас не выйдет в виду непонимания тобой того о чем говорю я. Очень советую поробовать почитать статьи по Немерле на нашем сайте. Может оказаться, что ты не только изменишь мнение, но и откроешь для себя много интересного. По крайней мере лично я открыл.
T>Кстати, если уж сопоставлять Спирит с сопоставлением, то какой класс грамматик поддерживает сопоставление в Немерле?
Немерле не построитель парсеров. Это язык программирования. По этому на нем у тебя нет ограничений в классе грамматик. В принципе средствами паттерн-матчинга хорошо парсятся LL(k)-грамматики с перемеменным ка. Но так как это полноценный ЯП, то нет проблем парсить грамматики любой сложности.
Самое же интересное, что в этот язык можно встроить парсер любой сложности. Более того один из обитателей этого сайта даже работает над одим таким проектом. А возможно это становится потому, что в Немерле есть офигительной мощьности макросы. По сравнению сними метапрограммирование на шаблонах С++ — это как копание траншеи вилкой супротив копания экскаватором. И я нисколько не приувиличивю.
T>Я согласен, что декларативный синтаксис, в частности сопоставление с образцом и списковые дополнения в сочетании со статической типизацией и автоматическим выводом типов очень удобные и мощные языковые механизмы. С их помощью многие вещи можно записать более выразительно.
Именно.
T>Но от того, что язык их содержит, он не становится автоматически лучшем_языком_в_мире_на_котором_невозможно_писать_неправильные_программы,
Об этом никто и не говрит. Но в купе с другими возможностяси он по крайней мере становится одинм и лучших практических языков имеющихся на сегодня.
T>и наоборот, не имеющий этих наворотов язык не становиться от этого полным_отстоем, как это можно заключить по твоим высказываниям.
Полным — конечно нет. Но и лучше от от этого никак стать не может. А в сочетани с граблями и досисторическими решениями вполе может стать скажем так сильно морально устаревшим.
T>Читая твои посты, создаётся впечатление, что мы не в форуме "философия программирования" а на митинге в поддержку .Net + ХХХ и заклеймению непохожих.
На самом деле мне плевать на .Net просто это один из инструментов предоставляющих мне некоторый набор возможнсотей (компонетность, модульность, динамичность... в сочетании со статической типизацией, быстрой и эффективной компиляцией). В общем, это тот рантайм который позволяет сделать возможным то что мне нравится. Причем он совсем не идеален. Как не идеален Немерле. Но по моим личным ктитериям это наиболее приятная копозиция возможностей и недостатков.
T>
T>Если тебе платят за это — скажи, я наверно пойму. (с) Б.Г.
Наверно если бы мне платили за то что я сижу на форуме, то я бы был уже давно миллиардер.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Мало того он признает что для прикладного программирования С++ не очень хорошо подходит именно из-за отсутствия GC и плохой компонентной модели.
Плохой? Во как! Век живи, век учись... дураком помрешь...
Откуда в С++ взялась компонентная модель?
Что касается прикладных задач... а какие задачи не прикладные?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
КЛ>это огромнейший недостаток. const это не только способ документирования кода, но и способ избавления от многих ошибок. В c# каждый метод — черный ящик. Что он может сделать с твоим объектом можно только догадываться.
С++ как способ избавиться от ошибок... (задумчиво) что-то в этом есть...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
КЛ>это не важно. Зуб даю, что до появления немерле он с таким же смаком ломал людям кайф и в неподходящих местах ругал с++ и хвалил c#. У него жизненное кредо такое, наверное.
КЛ>это огромнейший недостаток. const это не только способ документирования кода, но и способ избавления от многих ошибок. В c# каждый метод — черный ящик. Что он может сделать с твоим объектом можно только догадываться.
КЛ>А как тебе читабельность?
КЛ>1) отмена :: есть большая ошибка. КЛ>2) возможность называть переменные, свойства и т.п. так же, как и типы — еще одна ошибка.
АХ>>С другой стороны и у C++ много косяков. Как насчет отсутствия override?
КЛ>ерунда.
АХ>>Также можно сказать, что так как в C++ нет GС, то писать на нем — это убийство .
КЛ>отсутствие GC — самое последнее, что заботит с++ программера. Конечно приходится "достраивать", используя smart pointers etc., но это настолько просто, что это даже не обсуждается. И это дает возможность выбора.
АХ>>Вообще для меня нет пока идеального языка.
КЛ>а его и не будет, наверное )
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
>> C>Ну так и в C# точно так же, используешь какой-нибудь системно-зависимый >> C> контрол — и привет портируемости. >> Ну естественно. Но это уж, что называется, сам виноват. C>Так вот, MS делает такие ляпы ну уж ОЧЕНЬ легкими.
Дело в том, что MS хорошо интегрировала .NET со своими предыдущими технологиями — COM, Win32,...
Это, естественно, не случайно .
>> Вот, например, возьмем тот же GUI. Каким он должен быть — на нативных >> контролах или одинаковый на всех платформах? Иконки растровые или >> векторные? Должен смену скинов поддерживать или нет? Слишком много >> разных требований, на всех не угодишь. C>Swing в Java Может использовать свои скины или эмуляцию родного GUI C>для платформы. Работает достаточно прилично.
А иконки там векторные?
>> C>Вот в Java, фактически, такой стандарт есть — это Sun JDK, который есть >> C>на куче платформ. А сейчас вообще открытым стал. >> Да, ну так там тоже зоопарк. GUI на чем делать — на AWT или Swing? C>AWT? Это что такое? здесь.
C>Сейчас есть два фреймворка — Swing и SWT. SWT — обертка над нативным API.
И AWT . Правда, насколько я понимаю, его уже мало кто использует.
Здравствуйте, eao197, Вы писали:
E>Тут, кстати, другое интересно -- механизм шаблонов и исключений был описан для C++ в 1988-1990 годах. Но в Java generic-и добавились только в 2003-м (если я не путаю дату выхода Java 1.5). А появившаяся в 2000-м первая версия C# так же не содержала generic-ов. И это не смотря на то, что шаблоны уже десять лет до этого демонстрировали свою полезность и востребованность! Так что еще совсем недавно C++ предоставлял разработчикам такие языковые возможности, которых не было у его конкурентов.
Небольшое дополнение. Generics, кроме синтаксиса, имеют относительно немного общего с шаблонами, так что и утверждение выше можно считать верным и сейчас. В обратную сторону оно тоже, естественно, верно, как и было верным в 2000-м.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Константин Л., Вы писали:
КЛ>чего стоит мой — я знаю.
Если у всех в вашей команде такой же опыт как у вашего веб-программиста, то дальше можешь не рассказывать. (подсказываю — люди пользуются многими другими браузерами, кроме IE6. И показывать им "ваш браузер не поддерживается" — вопиющий непрофессионализм)
Здравствуйте, WolfHound, Вы писали:
FR>>И для C++ и для разных вариантов GC есть неблокирующие или малоблокирующие распределители памяти, так что подавать это как преимущество GC неккоректно.
WH>Нука покажи мне реализацию неблокирующего менеджера памяти для С++.
Здравствуйте, VladD2, Вы писали:
VD>Дык не развешивай. Я выражаю свое мнение. В 21 веке С++ не место. Это динозавро который забыл вымереть.
Если сам не забыл, то другие не дали. Если язык живет, то кому-то это нужно. Другое дело, что приложения масштаба предприятия на нем писать нецелесообразно, но это уже другой разговор.
Здравствуйте, WolfHound, Вы писали:
WH>>>Там очень легко делается по куче на процессор. CC>>Грубо говоря по куче на поток. WH>Нет. Кучу нужно вешать на процессор.
Резонно, но только в случае если на одном процессоре гарантировать, что во время выделения памяти не произойдет переключения потока. А это опять к локам сводится...
CC>>Это можно и без GC. WH>Очень сложно. Есть проблемы с удалением объектов созданных в другом потоке.
Если откопаю — кину ссылку на библу которая так делает. Насколько я помню там что то вроде отложенного освобождения.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, VladD2, Вы писали:
VD>В 21 веке С++ не место. Это динозавро который забыл вымереть.
21-й век давно уже идет. C++ все еще здесь. И будет здесь еще долго.
Я уверен, что за время его жизни ты еще успеешь сменить несколько своих любимых игрушек, обгадив при этом все предыдущие.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, Константин Л., Вы писали:
КЛ>>>>Хе-хе. Она мне в с# почти ни разу не пригодилась, не говоря уже о с++. Имхо рефлексия нужна там, где есть ошибки проектирования КЛ>>>> (сериализацию и т.п. в расчет не берем).
АХ>>>Почему не берем? Это одна из базовых и необходимейших задач, а ее значение в свете веб-сервисов еще важнее. А также сюда же AOP, Unit Tests и еще много других нужных и полезных технологий.
КЛ>>SOAP сериализация — да. Вэб-сервисы — частный случай.
АХ>Да это для начала. Применений рефлексии еще полно. Да хотя бы нормальный вывод сообщений об ошибках. __FILE__, __LINE__ недостаточно.
и в чем же она нам тут поможет?
КЛ>>Поддержка AOP должна быть на уровне языка.
АХ>Уровень языка должен быть таким чтобы ее можно было безболезненно встроить с помощью подключаемой библиотеки. В этом помогут атрибуты.
не согласен. Полноценный AOP на рефлексии и атрибутах не построишь
АХ>>>COM — это кроссязыковая технология и при этом такой жутик, что MS пришлось сделать .NET. При этом собственно изначально .NET возник из проекта по добавлению метаданных к C++ (здесь), но в процессе оказалось что для полноценной компонентной технологии этого мало.
КЛ>>жутик? А может просто у некоторых людей проблемы с с++ и COM и им надо что-то попроще?
АХ>У самой MS с ним были проблемы, поэтому они и создали .NET. АХ>Дело не в "попроще", а в "логичнее, надежнее и больше возможностей."
ну да. но вот только зачем мне портить настроение? Пусть каждый живет чем хочет.
АХ>Для того, чтобы пользоваться COM мне еще надо всякие дурацкие нестандартные IDL-костыли вроде [in],[out] прикручивать, а потом пропускать через MIDL. Да и вообще даже с ATL с COM столько дурацкой тупой возни, да хотя бы с теми же GUIDами/CLSIDами, что застрелиться можно, а код замусорен макросами.
это какие-то они нестандартные и дурацкие? Это всего-лишь указания на способ передачи параметров. Что тебя тут смущает?
Как ты себе это представляешь по-другому? Какая возня? У меня нету возни с гуидами. Что-то ты путаешь.
АХ>Ну и к тому же COM поддерживает очень малую часть возможностей C++. АХ>Как мне с помощью COM любой стандартный контейнер типа std::vector передать ? АХ>Или boost::lambda воспользоваться? АХ>А могу ли я сделать шаблонную библиотеку? АХ>Как насчет исключений?
все так. Но какая альтернатива у .net? Remoting? те же яйца только в профиль.
КЛ>> Ну так пусть юзают что попроще, но к нам сюда не лезут.
АХ>Мы уж лучше что помощнее. Попроще это к PHP-товарищам.
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, Константин Л., Вы писали:
КЛ>>чего стоит мой — я знаю.
AF>Если у всех в вашей команде такой же опыт как у вашего веб-программиста, то дальше можешь не рассказывать. (подсказываю — люди пользуются многими другими браузерами, кроме IE6. И показывать им "ваш браузер не поддерживается" — вопиющий непрофессионализм)
не говори о том, чего не знаешь. Это просто смешно. Очень очень смешно. К сожалению я не могу раскрывать имена заказчиков. Всем бы таких, да далеко не все могут получить.
Здравствуйте, VladD2, Вы писали:
VD>А ничего. Используется один из примитивнеших алгоритмов. На простых тестах довольно шустро, но в реальных условиях практически не применимо. Тут где-то рядом кто-то делал тест (после пиара Губановым крутости ЖЦ Оберона), так там Оберон умер после создания нного количества объектов.
Поискал, к сожалению, не нашел... т.к. флейма больно много в поиске находится... а вот вам еще коллега контр-тесты привел...
Я, лично, понимаю, что можно подобрать именно такие тесты в которых выигрышь будет на нужной стороне. Вопрос в том, как себя будет вести ГЦ в реальных приложениях, в которых ведется активное выделение памяти?
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, dr.Chaos, Вы писали:
DC>>>>ИМХО С++ довольно неплохо подходит для создания графических движков, это одна из тех задач, откуда его будет очень не просто вытеснить .
K>>>Да на ассемблере тоже можно неплохой движок написать. DC>>Напиши . Я хочу на это посмотреть . Видел демки 200-300Кб с нормально 3D графикой и музыкой, но это не движок
K>Да ладно, не вопрос. Только мне понадобится $2'000'000'000 и 10 лет.
А теперь приведи такие же цифры для С++ и других технологий, при этом чтоб скорость и удобство были на одном уровне . Причем желательно обосновать эти цифры, впрочем как и предыдущую.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Мало того он признает что для прикладного программирования С++ не очень хорошо подходит именно из-за отсутствия GC и плохой компонентной модели.
VD>Плохой? Во как! Век живи, век учись... дураком помрешь...
VD>Откуда в С++ взялась компонентная модель?
Ну в виде dll и статических библиотек она таки есть.
VD>Что касается прикладных задач... а какие задачи не прикладные?
Влад если еще не читал "Дизайн и эволюция С++" Страуструпа очень рекомендую он там довольно подробно все написал.
Как сильные стороны С++ он обозначил:
низкоуровневое системное программирование
высокоуровневое системное программирование
встроенные системы
численные и научные расчеты
общее прикладное программирование (с определенными оговорками)
Если интересно ознакомься подробнее сам.
ЗЫ Могу книгу по почте прислать на русском .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Что именно? То что неплохо подходит или то что непросто вытеснить? Хм, а графический движок не с битами возиться? Или я чего-то недопонимаю?
VD>Нет, не с битами. Они уже давно такой фигней не страдают. Почитай внимательно призентацию. Там есть про это не мало слов. На ассемблере они уже ничего не пишут. Все вычисления хотят сделать фукнциональными, чтобы ошибок по меньше было, и чтобы параллелились они хорошо.
Статью прочту позже.
По поводу того с чем работает движок мне рассказывать не надо , мне приходилось участвовать в разработке одного движка.
VD>Графика давно живет в разных дитеркиксах и шейдерах.
Кроме того FR вроде сказал что они предъявляли требования к не к языку реализации, а к языку прикладной логики.
DC>>Дык я и не утверждал что инструмент лучший. Но только на данный момент есть только требования к новому языку, но языка то еще нет. Так что мимо кассы, как появиться инструмент так и говорить можно будет.
VD>В общем-то ОКамл или Немерле удовлетворяют большинству указанных там требований. Не всем конечно, но уж точно они в сто раз ближе к тому идеалу чем С++.
А движки на них есть?
VD>Собственно весь разговор о том, что ищется замена С++.
DC>>Полагаю что новый стандарт решит часть проблем в С++.
VD>Ни одной!
Здорово, вот сошлась куча специалистов отрасли, потрындела 10 лет и в итоге выдала полный бред?? Я так понял твое высказывание? Т.е. несколько сотен непоследних специалистов по твоему неспособны решать какие-либо проблемы?
Здорово . Аплодирую стоя.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
на более важный, с моей точки зрения вопрос Влада, ты не ответил, а именно
Скромный список вопросов.
1. Ты лично занимался обеспечением работоспособности "вашего двигла" на этих платформах?
2. В какой игре можно увидить "ваше двигло"?
3. Сколько лет вы его разрабатываете?
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, jazzer, Вы писали:
J>>Разница была еще и в том, что Ада не была объектно-ориентированной.
K>А вот это смотря что считать ООП. В Аде 83 года не было tagged types. Это что-то вроде virtual в C++. Причём не сказать, что в Аде вообще не было ООП. Были инкапсуляция, наследование. А с полиморфизмом разобрались только к 95 (точно не знаю, но видимо до этого его реализовывали обходными путями). При этом в стандарте 83 года уже были generics.
Когда, когда в Ада появилось наследование?? в 83?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, ironwit, Вы писали:
I>1. Ты лично занимался обеспечением работоспособности "вашего двигла" на этих платформах?
К тому моменту как я пришел — для PS2/первый XBOX уже было сделано. Дальше — NDA I>2. В какой игре можно увидить "ваше двигло"?
Старая версия — Corvette. Новая — в разработке. Дальше — NDA
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Андрей Хропов wrote: > C>Так вот, MS делает такие ляпы ну уж ОЧЕНЬ легкими. > Дело в том, что MS хорошо интегрировала .NET со своими предыдущими > технологиями — COM, Win32,... > Это, естественно, не случайно .
Вот поэтому его и не надо использовать. Нужно юзать технологии от
компаний для которых слово "портируемость" не значит "легкая возможность
перенести софт на Windows".
> C>Swing в Java Может использовать свои скины или эмуляцию родного GUI > C>для платформы. Работает достаточно прилично. > А иконки там векторные?
Нет, но в принципе сделать можно. Уже есть аппаратно ускореный Java2D, я
на нем делал красивый realtime-view для сети датчиков. Все вполне шустро
работало.
> C>AWT? Это что такое? > здесь <http://en.wikipedia.org/wiki/Abstract_Window_Toolkit>.
Это был сарказм
Просто голый AWT сейчас никто не использует. Я навскидку ни одного
проекта даже не вспомню.
> C>Сейчас есть два фреймворка — Swing и SWT. SWT — обертка над нативным API. > И AWT . Правда, насколько я понимаю, его уже мало кто использует.
Он мутировал и используется для низкоуровневых графических целей. Типа
загрузки изображений или базы для Swing'а.
Здравствуйте, Константин Л., Вы писали:
КЛ>хм...По-моему тут унижает себя сам только один человек, и это не я. Задумайся над этим. Ты у меня уже давно потерял уважение. Думаю не только у меня. Ну это уже твои проблемы.
Здравствуйте, dr.Chaos, Вы писали:
DC>Здорово, вот сошлась куча специалистов отрасли, потрындела 10 лет и в итоге выдала полный бред?? Я так понял твое высказывание? Т.е. несколько сотен непоследних специалистов по твоему неспособны решать какие-либо проблемы?
DC>Здорово . Аплодирую стоя.
Аплодировать нужно Р. Хайнлайну:
- Забудь об этом, дорогой. Лучше скажи мне, какой план они, по-твоему, изберут?
— На этой сходке?
— Да.
— Конечно же, никакой. Они не придут ни к какому решению. Мэри, комитет — это единственная известная форма жизни с сотней желудков и без малейшего намека на мозг. В конце концов кто-нибудь, у кого есть своя голова на плечах, заставит их принять его план. Правда, вот не могу сказать, каким он будет.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, remark, Вы писали:
R>К сожалению в области создания ПО сейчас сложилась очень нездоровая ситуация, когда многие (причём и люди очень высокого звена) считают, что не надо использовать _сложные_ языки и не надо нанимать опытных профессионалов, всё тоже для них смогут сделать студенты на новом разрекламированном языке.
Добавлю я сюда свои 3 копейки.
В историческом плане развтитие языков "арифметического" типа (это значит, что я не намерен здесь обсуждать Лисп, Пролог и т.д.) шло по двум направлениям. Грубо говоря — одно от Фортрана, другое — от Бейсика. Одно — профессиональное и только профессиональное, дилетантам там нечего делать. Другое — для дилетантов. В одном случае имелось целью взять от машины все, что можно, в другом — сделать что-нибудь простенькое, хоть как-нибудь.
Оба эти подхода имеют право на существование. Действительно, сотруднику какой-то научной лаборатории, которому надо эксперимент обсчитывать (ну там 5-10 тысяч арифметических операций на расчет) совсем незачем становиться профессиональным программистом, Освой за пару недель Бейсик, напиши свою регрессию, и радуйся. И наоборот, профессионалы Бейсиком практически не интересовались.
Ситуация стала меняться, когда потребовались профессионалы в большем количестве, чем раньше. Подготовка настоящего профессионала требует и времени, и денег, да и способностей тоже. А рынок требовал своего. Эту ситуацию гениально ухватила Микрософт, которая начала подтягивать свой VB к серьезным языкам. Если Бейсик до VB был языком просто презираемым, то про VB это уже сказать было нельзя.
В результате те, кто раньше никак себя к профессионалам не относил, почувствовали. что и они что-то могут! Иными словами, за их программы на VB им будут платить. Не только за те програамы, что создаются для себя или своей конторы мимоходом, но и , как оказалось, можно и для других такое писать и продавать. Эффективность там, конечно, не та, качество не то, да ведь другого все равно нет. Есть спрос — есть предложение. Во времена экспоненциального развития все будет потреблено, если оно хотя бы чего-то стоит. Конечно, Photoshop или AutoCad они не напишут, да никто и не требует.
В общем, эффективностью пожертвовали ради удобства и простоты. Тем более тут еще бум с ростом ресурсов произошел очень кстати, так что порой и незаметно было , что этот продукт работает в 10 раз медленнее, чем ему положено. Самолет для меня — штука прекрасная, откуда мне знать — его 900 км/час это нормально или нет ? Может, нормально 3000 км/час ? Ничего я в самолетах и аэродинамике не понимаю (допустим) . Все равно, и 900 лучше, чем поездом!
Ну а дальше началось то, что называется "террор среды". Проще говоря. эта среда начала диктовать свои правила и профессионалам — они начали так или иначе эти новые правила игры принимать. Не все, конечно, но многие. Ну и соответствующие средства появились — Java, потом .Net, хоть и идеология от VB, но синтаксис и семантика нормальные. Удобно. Легко. Просто. Много знать не надо — садись и пиши. Что надо — по ходу действия разберешься. И заменить тебя, если что , легко — поточное производство. Качество ? Да ладно вам, летает ведь. Что, говорите, быстрее должен летать ? В 5 раз быстрее, говорите, должен ? Ну и идите стройте его, этот самолет, а пока Вы его построите, мы этот сломаем и новый построим. Он, правда, летать не быстрее будет...
Когда это кончится ? Скорее всего, никогда, обратного хода нет. Правда, одно "но" есть. Если рост ресурсов приостановится (а похоже, к этому дело идет), то качество выйдет на поверхность заново. Просто потому, что с усложнением задач станет ясно, что для их реализации нужны опять эффективные методы, а не сборка на коленках. Но до этого еще ИМХО очень далеко. Тем более, что если брать бизнес-сферу, то сложность задач там для 90% не бог весть какая, и вряд ли она сильно усложнится — нет предметной области. Не знаю, как будут выглядеть , скажем, сайты торгующих фирм или турфирм через 10 лет, но продавать или предлагать они будут, в общем, то же самое...
R>[q] R>why do I see character echo delays in Word on my 2GHz, 2Gb computer? I didn’t see that on my editor on a shared 1MHz, 1Mb PDP11 25 years ago
А вот именно поэтому.
И не надо мне говорить, что Word на C++ написан. Я это знаю. И на С++ можно написать такое, что будет летать со скоростью кукурузника. Если постараться
Вот наборот — вряд ли. Самолет ехать может. Электровозы не летают.
Здравствуйте, dr.Chaos, Вы писали:
DC>Ну в виде dll и статических библиотек она таки есть.
Статических библиотек? Ты шутишь?
В прочем, ни статических библиотек, ни dll в С++ нет. Все это особенности реализации конкретных компиляторов не совместимые между собой.
VD>>Что касается прикладных задач... а какие задачи не прикладные?
DC>Влад если еще не читал "Дизайн и эволюция С++" Страуструпа очень рекомендую он там довольно подробно все написал.
Спасибо за совет, но я просил дать ответ на вопрос.
DC>Как сильные стороны С++ он обозначил: DC>
DC>низкоуровневое системное программирование DC>высокоуровневое системное программирование DC>встроенные системы DC>численные и научные расчеты DC>общее прикладное программирование (с определенными оговорками) DC>
Это все мнение о С++ не имеющее ничего общего сдействительностью. Я просил назвать задачи которые на С++ решать удобнее нежели на ндругих средствах.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, dr.Chaos, Вы писали:
DC>>Здорово, вот сошлась куча специалистов отрасли, потрындела 10 лет и в итоге выдала полный бред?? Я так понял твое высказывание? Т.е. несколько сотен непоследних специалистов по твоему неспособны решать какие-либо проблемы?
DC>>Здорово . Аплодирую стоя. S>Аплодировать нужно Р. Хайнлайну: S>
S>- Забудь об этом, дорогой. Лучше скажи мне, какой план они, по-твоему, изберут?
S>- На этой сходке?
S>- Да.
S>- Конечно же, никакой. Они не придут ни к какому решению. Мэри, комитет — это единственная известная форма жизни с сотней желудков и без малейшего намека на мозг. В конце концов кто-нибудь, у кого есть своя голова на плечах, заставит их принять его план. Правда, вот не могу сказать, каким он будет.
S>)
Красиво слил, чесслово. . .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Возможно успею даже умереть, но это не делает чести человечеству, а показывает его главне недостатки — костность, ленивость и глупость.
Не совсем согласен. Для некоторых задач целесообразно использовать именно С++. То, что он останется, покажет лишь полезность языка в данных условиях. И не более.
Здравствуйте, VladD2, Вы писали:
VD>В прочем, ни статических библиотек, ни dll в С++ нет. Все это особенности реализации конкретных компиляторов не совместимые между собой.
Ну почему, все что подчиняется правилам компоновки С может быть слинковано и работать себе без особых проблем.
VD>>>Что касается прикладных задач... а какие задачи не прикладные?
DC>>Влад если еще не читал "Дизайн и эволюция С++" Страуструпа очень рекомендую он там довольно подробно все написал.
VD>Спасибо за совет, но я просил дать ответ на вопрос.
DC>>Как сильные стороны С++ он обозначил: DC>>
DC>>низкоуровневое системное программирование DC>>высокоуровневое системное программирование DC>>встроенные системы DC>>численные и научные расчеты DC>>общее прикладное программирование (с определенными оговорками) DC>>
VD>Это все мнение о С++ не имеющее ничего общего сдействительностью. Я просил назвать задачи которые на С++ решать удобнее нежели на ндругих средствах.
Где?
Вот твой вопрос:
Что касается прикладных задач... а какие задачи не прикладные?
На что я тебе привел мнение создателя языка. Или я чего не домыслил в твоем вопросе? .
Но твой вопрос все таки постараюсь ответить. Но сначала уточни — какие именно другие средства, ты имеешь ввиду?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Если в сравнении с C# 2.0 С++ и может еще что-то противопоставить, то в сравнении с Nemerle он сливает по всем пунктам кроме скорости и потреблению памяти в конечных приложениях. Но и тут он не так уж и сильно впереди. И что самое главное с ростом производительности железа и оттачичанием технологий С++ становится все менее и мее актуальным.
VD>В области, прикладного программирования в С++ уже сосем мало тлка. Скоро очередь дойдет и до относительно системного ПО. Первыми будут компиляторы и IDE, а там и до всяких вордов не далеко.
Разговоры такие уже лет 15 ведутся, а возок все там же — связка из ядра на С/С++ и domain specific language поверх него решает большинство реальных задач.
Вопрос — почему так? Да потому, что прикладные области реально разные. И исполняющие ядра тоже нужны разные. И прикладные языки поверх ядер — тоже.
Здравствуйте, dr.Chaos, Вы писали:
DC>По поводу того с чем работает движок мне рассказывать не надо , мне приходилось участвовать в разработке одного движка.
И что из этого следует? Это твои фобии ничего не имеющие общего с реальность. МС уж точно не стала бы делать управляемый фрэймворк если бы заранее было известно, что он не приемлем попроизводительности.
DC>Кроме того FR вроде сказал что они предъявляли требования к не к языку реализации, а к языку прикладной логики.
Он часто говорит странные вещи. Ссылу на презентацию я дла. Там всего десятка два экранов. Что тут обсуждать то?
Там даже вычислительные ресурсы в гигафлопсах оцененные есть.
VD>>В общем-то ОКамл или Немерле удовлетворяют большинству указанных там требований. Не всем конечно, но уж точно они в сто раз ближе к тому идеалу чем С++.
DC>А движки на них есть?
Да. На ОКамле даже не мало рендереров написано. А для них вычислительные возможности отнюдь не лишние.
DC>Здорово, вот сошлась куча специалистов отрасли, потрындела 10 лет и в итоге выдала полный бред??
Я говорю о конкретных требованиях конкретного человека. Блин, скачай ppt-у и пчитай. В его требованиях основными критериями являются надежность и безопасность. Ни шагу в этом направлении в новм стандарте нет.
DC> Я так понял твое высказывание? Т.е. несколько сотен непоследних специалистов по твоему неспособны решать какие-либо проблемы?
По этому поводу отлично ответил Синклер.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Ну почему, все что подчиняется правилам компоновки С может быть слинковано и работать себе без особых проблем.
Ссылу на эти правила, плиз. По моим сведниниям стандарт С++ никаких правил не определяет, и стандартов де-факто тоже нет.
DC>Где? DC>Вот твой вопрос:
DC>
DC>Что касается прикладных задач... а какие задачи не прикладные?
DC>На что я тебе привел мнение создателя языка. Или я чего не домыслил в твоем вопросе? .
Я просил привести списко задач, а не тавои измышления о С++. Улавливаешь разницу?
DC>Но твой вопрос все таки постараюсь ответить. Но сначала уточни — какие именно другие средства, ты имеешь ввиду?
А какая разница? К задачам это отношения не имеет. Средства могут различаться в зависимости от задач.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
CC>К тому моменту как я пришел — для PS2/первый XBOX уже было сделано. Дальше — NDA I>>2. В какой игре можно увидить "ваше двигло"? CC>Старая версия — Corvette. Новая — в разработке. Дальше — NDA
Ясно, Борман, значит и вы не знаете как размножаются ёжики... (с)
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
E>>Тут, кстати, другое интересно -- механизм шаблонов и исключений был описан для C++ в 1988-1990 годах. Но в Java generic-и добавились только в 2003-м (если я не путаю дату выхода Java 1.5). А появившаяся в 2000-м первая версия C# так же не содержала generic-ов. И это не смотря на то, что шаблоны уже десять лет до этого демонстрировали свою полезность и востребованность! Так что еще совсем недавно C++ предоставлял разработчикам такие языковые возможности, которых не было у его конкурентов.
ПК>Небольшое дополнение. Generics, кроме синтаксиса, имеют относительно немного общего с шаблонами, так что и утверждение выше можно считать верным и сейчас. В обратную сторону оно тоже, естественно, верно, как и было верным в 2000-м.
Да, да, для тех кто не вылез за пределы С++ верным. Тем же кто слышал слова ML, O'Caml, и т.п. вряд ли такие слова покажутся верными.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
КЛ>не говори о том, чего не знаешь. Это просто смешно. Очень очень смешно. К сожалению я не могу раскрывать имена заказчиков. Всем бы таких, да далеко не все могут получить.
Правильно! Никому их имена не рассказвай, а то они узнают кто им код пишут и офигет сразу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Hobot Bobot, Вы писали:
HB>Однозначного отображения процесса строительства на процесс программирования нет и, ясен пень, быть не может. Впрочем, думаю, что между рядовым строителем и программистом, пишущим код по подробной спецификации, общего достаточно для проведения аналогий.
Аналогии можно провести между много чем. Только одни получаются ближе чем другие
И к "программисту, пишущему код по подробной спецификации", все же гораздо ближе младший инженер, делающий чертеж отдельных несложных этажей по подробной спецификации, составленной ведущим инженером
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну а дальше началось то, что называется "террор среды". Проще говоря. эта среда начала диктовать свои правила и профессионалам — они начали так или иначе эти новые правила игры принимать. Не все, конечно, но многие. Ну и соответствующие средства появились — Java, потом .Net, хоть и идеология от VB, но синтаксис и семантика нормальные. Удобно. Легко. Просто. Много знать не надо — садись и пиши. Что надо — по ходу действия разберешься. И заменить тебя, если что , легко — поточное производство. Качество ? Да ладно вам, летает ведь. Что, говорите, быстрее должен летать ? В 5 раз быстрее, говорите, должен ? Ну и идите стройте его, этот самолет, а пока Вы его построите, мы этот сломаем и новый построим. Он, правда, летать не быстрее будет...
Самолет, которого нет, летает с нулевой скоростью. "Профессионалы", которые строят гипотетические самолеты, которые должны летать быстрее в 5 раз, но не летают вообще — это не профессионалы.
Здравствуйте, Andir, Вы писали:
АХ>>а вот библиотек больше всего у MS.NET.
A>Основания у такого заявления есть? В том смысле хотелось бы узнать источник таких данных.
Reflector?
У меня даже нет сомнения, что если отбросить Яву, то это чистейшая правда.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Ну а дальше началось то, что называется "террор среды". Проще говоря. эта среда начала диктовать свои правила и профессионалам — они начали так или иначе эти новые правила игры принимать. Не все, конечно, но многие. Ну и соответствующие средства появились — Java, потом .Net, хоть и идеология от VB, но синтаксис и семантика нормальные. Удобно. Легко. Просто. Много знать не надо — садись и пиши. Что надо — по ходу действия разберешься. И заменить тебя, если что , легко — поточное производство. Качество ? Да ладно вам, летает ведь. Что, говорите, быстрее должен летать ? В 5 раз быстрее, говорите, должен ? Ну и идите стройте его, этот самолет, а пока Вы его построите, мы этот сломаем и новый построим. Он, правда, летать не быстрее будет...
AF>Самолет, которого нет, летает с нулевой скоростью. "Профессионалы", которые строят гипотетические самолеты, которые должны летать быстрее в 5 раз, но не летают вообще — это не профессионалы.
Может быть правильней сказать, что одни делают электровозы, а другие — самолёты?
Конструктор электровоза самолёт не спроектирует, а наоборот — вполне.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, dr.Chaos, Вы писали:
DC>>Красиво слил, чесслово. . . WH>Почему слил? Лично я еще ничего хорошего разработанного комитетом не видел.
А ты видимо главный оценщик и цензор?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>По поводу того с чем работает движок мне рассказывать не надо , мне приходилось участвовать в разработке одного движка.
VD>И что из этого следует? Это твои фобии ничего не имеющие общего с реальность. МС уж точно не стала бы делать управляемый фрэймворк если бы заранее было известно, что он не приемлем попроизводительности.
Влад я сказал, что в MC не смогут разработать нормальный фреймворк для этого? Мало того после требований Висты, что-то у меня возникают сильные опасения, что "приемлемым по производительности" оно станет благодаря новым железкам, а не разработчикам в MC.
VD>>>В общем-то ОКамл или Немерле удовлетворяют большинству указанных там требований. Не всем конечно, но уж точно они в сто раз ближе к тому идеалу чем С++.
DC>>А движки на них есть?
VD>Да. На ОКамле даже не мало рендереров написано. А для них вычислительные возможности отнюдь не лишние.
Рендерер = Движок ?
DC>>Здорово, вот сошлась куча специалистов отрасли, потрындела 10 лет и в итоге выдала полный бред??
VD>Я говорю о конкретных требованиях конкретного человека. Блин, скачай ppt-у и пчитай. В его требованиях основными критериями являются надежность и безопасность. Ни шагу в этом направлении в новм стандарте нет.
Хм, ну С++ вобщем то универсальный язык, полагаю комитет руководствовался не пожеланиями конкретного человека. Верю что решения комитета могут не решить его проблем. Но утверждать, что улучшения которые появятся в 2009 году — бред, который ничего не изменит — глупо, по меньшей мере.
DC>> Я так понял твое высказывание? Т.е. несколько сотен непоследних специалистов по твоему неспособны решать какие-либо проблемы?
VD>По этому поводу отлично ответил Синклер.
Сразу видно команда . Ты пойми Влад, я не против новых инструментов, если они появятся и решат проблемы в какой-то отрасли это просто здорово. Но просто не понимаю смысла говнять имеющийся инструментарий. Язык С++ далеко не идеален, но он достаточно хорош для решения большинства задач.
Вернемся к началу. Т.е. ты считаешь что С++ из области написания графических движков вытеснит другой инструмент типа Немерле или ОКамл? Поскольку требования к языку в статье и немало рендереров на ОКамле являют какую-то тенденцию. Когда это по твоему произойдет?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Ну почему, все что подчиняется правилам компоновки С может быть слинковано и работать себе без особых проблем.
VD>Ссылу на эти правила, плиз. По моим сведниниям стандарт С++ никаких правил не определяет, и стандартов де-факто тоже нет.
Стандарт С++ их и не регламентирует. Влад я думаю ты прекрасно знаешь принцип работы простейшего компоновщика, который заменяет имена функций и переменных, определенных в др единице компиляции, на их адрес. Не знаю есть ли стандарт или какие-то регламентирующие документы, если тебе это так важно могу поискать.
DC>>Где? DC>>Вот твой вопрос:
DC>>
DC>>Что касается прикладных задач... а какие задачи не прикладные?
DC>>На что я тебе привел мнение создателя языка. Или я чего не домыслил в твоем вопросе? .
VD>Я просил привести списко задач, а не тавои измышления о С++. Улавливаешь разницу?
Хм, значит так спросил что я тебя не понял. Мало того привел я не свои измышления, а цитату из книги Страуструпа. Улавливаешь разницу? Правда, извини, не оформил как цитату, но указал что это не мои слова.
А по поводу задач: задачи системного программирования: написание ОС, драйверов, компиляторов и т.п. Хотя я думаю, что для написания компиляторов есть более подходящие инструменты, но я тут профан . Научные расчеты на большом количестве процессоров (ядер), будут быстрее выполнять функциональные языки, хотя в общем случае — . По поду прикладного ПО — вполне можно использовать С++ для написания ядра системы, а сверху накручивать прикладную логику каким-нибудь интерпретируемым языком, если грамотно сделать то будет и эффективность и скорость разработки.
DC>>Но твой вопрос все таки постараюсь ответить. Но сначала уточни — какие именно другие средства, ты имеешь ввиду?
VD>А какая разница? К задачам это отношения не имеет. Средства могут различаться в зависимости от задач.
Тогда зачем спрашивал?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, AndreiF, Вы писали:
AF>>> Так что вопрос можно поставить и обратный — а ты напишешь Quake 4 на чистом С++? CC>>Да. CC>>В том же Q4 скрипты предназначены только для того, чтобы можно было быстро и просто менять игровую логику не пересобирая движок. CC>>Ничто в общем то не мешает весь этот код запихать в DLL как это было во времена того же HL.
AF>Смелый парень. И много квейков 4, или хотя бы ХЛов ты за свою жизнь написал?
Парень он, возможно, смелый, зато работает, судя по профилю, в геймдеве. А вот ты, судя по высказываниям — нет. Не мог бы для начала привести какое-нибудь подтверджение вот этому своему высказыванию:
На самом деле, большая (по объему) часть современных игр пишется как раз на скриптах, в том числе и Питоне. Эта часть как правило больше, чем часть кода написанного на С++.
Здравствуйте, dr.Chaos, Вы писали: DC>Стандарт С++ их и не регламентирует. Влад я думаю ты прекрасно знаешь принцип работы простейшего компоновщика, который заменяет имена функций и переменных, определенных в др единице компиляции, на их адрес. Не знаю есть ли стандарт или какие-то регламентирующие документы, если тебе это так важно могу поискать.
Я тебе поясню скепсис Влада: во времена С всё, с чем работал линкер — тупые текстовые имена. А поскольку кроме глобальных переменных и функций линковать было нечего, то не было и проблем. А в С++ сразу появляются проблемы с перегрузкой функций и линковкой классов. Поскольку линкер ничего не знает про сигнатуры, для функций приходится выполнять так называемый манглинг, т.е. формирование "внутреннего" имени из настоящего имени и типов аргументов. Никакого стандарта на этот манглинг в природе не существует, поэтому С++ библиотеки от разных компиляторов между собой не совместимы. Это уже копец.
Далее, Страуструп намеренно отказался от стандартизации внутреннего представления метаданных. Т.е. всё, начиная от VMT и заканчивая таблицей фиксапов для приведения типов при множественном наследовании отдается на откуп компилятору. И, естественно, в этом компиляторы тоже несовместимы. Поэтому взять и отнаследоваться в компиляторе X от класса, определенного в библиотеке, скомпилированной компилятором Y в общем случае нельзя.
DLL в эту благостную картину ничего нового не добавляют. Они работают точно так же — биндинг к адресу по имени — только в рантайме, а не при компоновке. Поэтому все проблемы несовместимости реализаций в них присутствуют в полный рост.
Вот COM откуда по-твоему вырос? А вот как раз из того и вырос, что надо было стандартизовать структуру VMT и способ приведения типа. Ну и еще много чего, чтобы можно было заставить разные реализации ООП интероперировать друг с другом. Это ответ на отсутствие стандарта ровно в тех областях, от которых отказался Бъярни.
DC>А по поводу задач: задачи системного программирования: написание ОС, драйверов, компиляторов и т.п. Хотя я думаю, что для написания компиляторов есть более подходящие инструменты, но я тут профан . Научные расчеты на большом количестве процессоров (ядер), будут быстрее выполнять функциональные языки, хотя в общем случае — . По поду прикладного ПО — вполне можно использовать С++ для написания ядра системы, а сверху накручивать прикладную логику каким-нибудь интерпретируемым языком, если грамотно сделать то будет и эффективность и скорость разработки.
DC>>>Но твой вопрос все таки постараюсь ответить. Но сначала уточни — какие именно другие средства, ты имеешь ввиду?
VD>>А какая разница? К задачам это отношения не имеет. Средства могут различаться в зависимости от задач.
DC>Тогда зачем спрашивал?
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, dr.Chaos, Вы писали:
DC>Вернемся к началу. Т.е. ты считаешь что С++ из области написания графических движков вытеснит другой инструмент типа Немерле или ОКамл?
Лично у меня нет сомнения в том, что это таки произойдет. Я, конечно, дилетант в гейминдустрии, но свои две копейки вставлю.
Насколько мне известно, плюсы — вовсе не такой уж суперпопулярный в ГД язык. Грубо говоря, современная игра состоит из трех уровней:
— низкоуровневые битхаки для рисования (ассемблер)
— ядро движка (С/С++)
— геймплей (язык описания уровней)
Оказывается, что очень большой вес играет именно последний уровень. Вон — почитай отзывы на конкурсах по разработке уровней. Банальное дописывание скрипта, который закрывает двери за героем может ускорить игру в два-три раза. Потому как главное в 21 веке — не выплевывание пикселов со скоростью шины, а аккуратное отсечение лишних треугольников
Опять же большую роль в скорострельности играет способность ядра использовать метаинформацию с верхнего уровня — в частности, просекать отсутствие необходимости рисовать треугоьники за закрытой дверью. Здесь рулят алгоритмы, а С++ не слишком-то хорошо подходит для написания сложных алгоритмов. Граблеват, знаете ли. Конечно, там очень удобно писать умножение матриц благодаря наличию шаблонов. Но все равно, специализированный DSL с поддержкой умножения матриц будет позволять записать алгоритмы компактнее, и оптимизироваться еще сильнее, чем С++. Так что есть у меня подозрение, что и для верхнего уровня, и для среднего слоя в геймдевелопменте должны рулить DSL.
Nemerle, в частности, выглядит как хороший кандидат для платформы для построения DSL. Конечно, старую гвардию на него не переведешь. Тот же Кармак собаку съел на С, он и на плюсы-то переходить не хочет (несмотря на то, что у них значительно более сильный оптимизатор). Так что платформа ждет своего героя — если вдруг появится хороший DSL для 3d-engine на Nemerle, народ достаточно быстро перелезет туда. Особенно c учетом перспективы получить поддержку снизу в виде компилятор типа Бартока для генерации нативного кода (чтобы успокоить тех, кто считает JIT слишком дорогим) и мегапроекта от МС с compile-time profile-based optimization.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndreiF, Вы писали:
E>>Не мог бы для начала привести какое-нибудь подтверджение вот этому своему высказыванию:
AF>Какая конкретно его часть нуждается в подтверждении?
Та, в которой написано, что объем кода на скриптовых языках в современных играх больше, чем объекм кода на С++. Как правило
Здравствуйте, Sinclair, Вы писали:
S>Я тебе поясню скепсис Влада: во времена С всё, с чем работал линкер — тупые текстовые имена. А поскольку кроме глобальных переменных и функций линковать было нечего, то не было и проблем. А в С++ сразу появляются проблемы с перегрузкой функций и линковкой классов. Поскольку линкер ничего не знает про сигнатуры, для функций приходится выполнять так называемый манглинг, т.е. формирование "внутреннего" имени из настоящего имени и типов аргументов. Никакого стандарта на этот манглинг в природе не существует, поэтому С++ библиотеки от разных компиляторов между собой не совместимы. Это уже копец.
Копец начался еще раньше, когда появились различные и несовместимые между собой форматы OBJ-файлов статических библиотек. Даже в рамках одной платформы. Причем C++ не имел к этому никакого отношения.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, dr.Chaos, Вы писали: DC>>Стандарт С++ их и не регламентирует. Влад я думаю ты прекрасно знаешь принцип работы простейшего компоновщика, который заменяет имена функций и переменных, определенных в др единице компиляции, на их адрес. Не знаю есть ли стандарт или какие-то регламентирующие документы, если тебе это так важно могу поискать. S>Я тебе поясню скепсис Влада: во времена С всё, с чем работал линкер — тупые текстовые имена. А поскольку кроме глобальных переменных и функций линковать было нечего, то не было и проблем. А в С++ сразу появляются проблемы с перегрузкой функций и линковкой классов. Поскольку линкер ничего не знает про сигнатуры, для функций приходится выполнять так называемый манглинг, т.е. формирование "внутреннего" имени из настоящего имени и типов аргументов. Никакого стандарта на этот манглинг в природе не существует, поэтому С++ библиотеки от разных компиляторов между собой не совместимы. Это уже копец.
Ооо. Ты открыл мне глаза
S>Далее, Страуструп намеренно отказался от стандартизации внутреннего представления метаданных. Т.е. всё, начиная от VMT и заканчивая таблицей фиксапов для приведения типов при множественном наследовании отдается на откуп компилятору. И, естественно, в этом компиляторы тоже несовместимы. Поэтому взять и отнаследоваться в компиляторе X от класса, определенного в библиотеке, скомпилированной компилятором Y в общем случае нельзя.
А ты себе представляешь сложность задачи? Унифицировать представление объектов в памяти на ВСЕХ возможных платформах. Кроме того к языку программирования это относится слабо. Кстати именно благодаря такому способу линковки С++ получил такое распространение и может использовать модули написанные на С, Fortran и т.д.
S>DLL в эту благостную картину ничего нового не добавляют. Они работают точно так же — биндинг к адресу по имени — только в рантайме, а не при компоновке. Поэтому все проблемы несовместимости реализаций в них присутствуют в полный рост.
S>Вот COM откуда по-твоему вырос? А вот как раз из того и вырос, что надо было стандартизовать структуру VMT и способ приведения типа. Ну и еще много чего, чтобы можно было заставить разные реализации ООП интероперировать друг с другом. Это ответ на отсутствие стандарта ровно в тех областях, от которых отказался Бъярни.
CORBA выросла примерно там же, только еще и с транспортом.
Я вот не пойму что вы мне пытаетесь доказать? То что сборки под дот нет или компоненты Делфи лучше? Дык я не спорю. Я сказал что благодаря, в том числе, такой компонентной модели С++ плох для прикладного ПО.
С чем ты споришь? Я понимаю что такая линковка — это тормозная и часто неудобная штука. Я понимаю что неунифицированное представление объектов — это проблемы совместимости платформ и компиляторов.НО!!! Простой как сибирский валенок механизм линковки, обеспечивает простоту реализации этого инструмента на любой платформе!! Мало того очень трудно сделать одинаково хорошее представление для микроконтроллера/PC/RISC-сервера/... Ты еще не забывай, что на специфических платформах нет ни шаблонов, ни множественного наследования и т.д. Т.е. создав единый стандарт представления — не угодили бы никому.
Помимо всего прочего — кто мешает, собраться MC, GNU GCC и Comeau — и сделать стандарт представления и ему следовать??
Правильно — деньги, очень не хочеться прибавлять их в чужом кармане. Разработчики компиляторов в этом не заинтересованы. А этот вопрос строго говоря языка то и не касается.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, dr.Chaos, Вы писали:
DC>>Вернемся к началу. Т.е. ты считаешь что С++ из области написания графических движков вытеснит другой инструмент типа Немерле или ОКамл? S>Лично у меня нет сомнения в том, что это таки произойдет. Я, конечно, дилетант в гейминдустрии, но свои две копейки вставлю. S>Насколько мне известно, плюсы — вовсе не такой уж суперпопулярный в ГД язык. Грубо говоря, современная игра состоит из трех уровней: S>- низкоуровневые битхаки для рисования (ассемблер)
Насколько я знаю — это в основном уже к шейдерам относиться. S>- ядро движка (С/С++) S>- геймплей (язык описания уровней)
Все верно.
Вот только я не заметил, чтоб было крайне сложно реализовать алгоритмы оптимизации сцены. Может я что-то не так делал? Море кода для этого, как открытого, так и не очень.
Собственно, С++ хорош не для ГД, а для 3D движка. В ГД — купил движок, накрутил скриптов, заплатил художникам — игра готова.
Ну чем Немерле принципиально лучше для алгоритмов оптимизации сцены? ФП? Я этот стиль и на С++ могу использовать, только он там редко где подойдет. Насколько я понимаю Немерле не чисто функциональный язык, поэтому оптимизации с многопоточностью здесь не пройдут, да и не видно пока 80-тиядерников.
Чем микрософтовские фреймворки для 3D принципиально лучше OpenGL — промышленного стандарта проверенного временем?
В чем принципиальное отличие о котором можно сказать — да это сильно упростит/удешевит/сделает более надежной разработку?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, dr.Chaos, Вы писали:
DC>>Вернемся к началу. Т.е. ты считаешь что С++ из области написания графических движков вытеснит другой инструмент типа Немерле или ОКамл? S>Лично у меня нет сомнения в том, что это таки произойдет. Я, конечно, дилетант в гейминдустрии, но свои две копейки вставлю. S>Насколько мне известно, плюсы — вовсе не такой уж суперпопулярный в ГД язык. Грубо говоря, современная игра состоит из трех уровней: S>- низкоуровневые битхаки для рисования (ассемблер)
Это уже давно все в видеокарте.
S>- ядро движка (С/С++)
Низкоуровневая физика отчасти тоже уже переезжает на видеокарту.
Остается просчет геометрии и физики на более высоком, глобальном, уровне (BSP, Quadtrees там всякие) и логика игры.
S>- геймплей (язык описания уровней)
S>Оказывается, что очень большой вес играет именно последний уровень. Вон — почитай отзывы на конкурсах по разработке уровней. Банальное дописывание скрипта, который закрывает двери за героем может ускорить игру в два-три раза.
Чего? Если игрок эту дверь не видит, то она сразу отсекается в любом нормальном движке еще задолго до растеризации вне зависимости от того закрыта она или нет.
S> Потому как главное в 21 веке — не выплевывание пикселов со скоростью шины, а аккуратное отсечение лишних треугольников
Главное в 21 веке — хороший геймплей и реклама .
S>Опять же большую роль в скорострельности играет способность ядра использовать метаинформацию с верхнего уровня — в частности, просекать отсутствие необходимости рисовать треугоьники за закрытой дверью. Здесь рулят алгоритмы, а С++ не слишком-то хорошо подходит для написания сложных алгоритмов. Граблеват, знаете ли.
Граблеват-то он граблеват. Но вот policy-based дизайн (т.е. параметризованные типы) замутить можно пока только в C++ или D нормально. Наверное, в Хаскеле (его Темплейт-вариации) тоже можно, но там ленивость...
S> Конечно, там очень удобно писать умножение матриц благодаря наличию шаблонов. Но все равно, специализированный DSL с поддержкой умножения матриц будет позволять записать алгоритмы компактнее, и оптимизироваться еще сильнее, чем С++.
Да ждем-с. Вот Fortress вышел, правда пока только интерпретатор.
S> Так что есть у меня подозрение, что и для верхнего уровня, и для среднего слоя в геймдевелопменте должны рулить DSL.
S>Nemerle, в частности, выглядит как хороший кандидат для платформы для построения DSL.
Вообще для DSL — да. Для игр — есть сомнения. Для этого нужны хотя бы slices для работы с матрицами (как в MATLAB, Python и D). Думаю поговорить об этом с авторами. Ну и опционально отменять поддержку выхода за границы массивов (в сложных алгоритмах может быть непоследовательный перебор элементов, и тут уже автоматом вывести то что проверять не надо сложновато).
S>Конечно, старую гвардию на него не переведешь. Тот же Кармак собаку съел на С, он и на плюсы-то переходить не хочет (несмотря на то, что у них значительно более сильный оптимизатор). Так что платформа ждет своего героя — если вдруг появится хороший DSL для 3d-engine на Nemerle, народ достаточно быстро перелезет туда.
Как бы переход managed-unmanaged не стал узким местом.
S>Особенно c учетом перспективы получить поддержку снизу в виде компилятор типа Бартока для генерации нативного кода (чтобы успокоить тех, кто считает JIT слишком дорогим) и мегапроекта от МС с compile-time profile-based optimization.
А я не понимаю, чего MS не выпустит его (Барток)
Здравствуйте, dr.Chaos, Вы писали:
DC>Стандарт С++ их и не регламентирует. Влад я думаю ты прекрасно знаешь принцип работы простейшего компоновщика, который заменяет имена функций и переменных, определенных в др единице компиляции, на их адрес. Не знаю есть ли стандарт или какие-то регламентирующие документы, если тебе это так важно могу поискать.
Я то как раз знаю. Стандартов нет. Точнее у каждого свои. Борланд с МС еще как-то пытались кооперироваться, но толку было мало. Интел еще что-то там под МС косить пытается. Но те же GCC и VC не совместимы. Так что С++ — переносим только на уровне исходников.
DC>А по поводу задач: задачи системного программирования: написание ОС, драйверов, компиляторов и т.п.
ОС, драверы и темболее компиляторы пишутся на управляемых языках ничем не хуже, и даже лучше. И если первое пока, что находится в эксперементальной стадии, то компиляторы уже давно пишутся как на управляемых языках так и на неуправляемых функцинальных. Причем все кто пробовал использовать хорошие ФЯ для написания компиляторов находят, что это значительно удобнее нежели использовать С/С++ для этой цели.
Так что это утверждение ошибочно. Это всего лишь самообман.
DC> Хотя я думаю, что для написания компиляторов есть более подходящие инструменты, но я тут профан .
Зато я кое что понимаю. С++ — это самый неудобный иструмент для этогою.
DC> По поду прикладного ПО — вполне можно использовать С++ для написания ядра системы, а сверху накручивать прикладную логику каким-нибудь интерпретируемым языком, если грамотно сделать то будет и эффективность и скорость разработки.
Остается вопрос зачем использовать С++ для того, что в несколько раз проще пишется на других языках? Я еще понимаю супер-корпорации вроде МС которые вполне могут позволить себе создать прототип, а потом приказать переписать его на С++ просто ради оптимизации. Но лишние мегабаксы есть только у 5-6 компаний в мире. Остальные живут в рамках жесточайшей конкурениции. И стло быть использовать С++ равносильно надеванию на себя гандикапа.
VD>>А какая разница? К задачам это отношения не имеет. Средства могут различаться в зависимости от задач.
DC>Тогда зачем спрашивал?
Затем, что С++ практически всегда наихудший выбор. Вот и интересно с какой целью люди выбирают именно его? Не уж то так тяжело переучиваться?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Копец начался еще раньше, когда появились различные и несовместимые между собой форматы OBJ-файлов статических библиотек. Даже в рамках одной платформы. Причем C++ не имел к этому никакого отношения.
Согласен. Но Страуструп был в силах это изменить. Если не в первой версии, то хотя бы во второй. Тогда он уже имел вес и мог диктовать условия.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC> Влад я сказал, что в MC не смогут разработать нормальный фреймворк для этого? Мало того после требований Висты, что-то у меня возникают сильные опасения, что "приемлемым по производительности" оно станет благодаря новым железкам, а не разработчикам в MC.
Виста как и другой софт выпскаемый МС создается в рассчете на сегодняшнее зелезо. И это правильно, так как если у меня в машине 3D-акселератор с поддержкой DX 9.0, двух-ядерный процессор и 1-2 гига памяти, то глупо не задействовать это богатство для улучшения комфорта и удобства. Лично Вистой я очень доволен.
DC>Рендерер = Движок ?
По вычислетльной нагрузке это значительно больше. По сложности алгоритмов — тоже.
DC>>>Здорово, вот сошлась куча специалистов отрасли, потрындела 10 лет и в итоге выдала полный бред??
VD>>Я говорю о конкретных требованиях конкретного человека. Блин, скачай ppt-у и пчитай. В его требованиях основными критериями являются надежность и безопасность. Ни шагу в этом направлении в новм стандарте нет.
DC>Хм, ну С++ вобщем то универсальный язык,
Ага. А в Киеве дядка. И что?
DC>полагаю комитет руководствовался не пожеланиями конкретного человека. Верю что решения комитета могут не решить его проблем. Но утверждать, что улучшения которые появятся в 2009 году — бред, который ничего не изменит — глупо, по меньшей мере.
Я не утверждал, что это бред. Я сказал, что С++ как раз то, что они исползуют и в чем находят (на мой взгляд совершенно обоснованно) море проблем. Интересно, что в качестве сравнения они использую C#, Java и Хаскель. Причем находят у всех языков ряд недостатков (впрочем как идостоинств).
DC>Сразу видно команда . Ты пойми Влад, я не против новых инструментов, если они появятся и решат проблемы в какой-то отрасли это просто здорово. Но просто не понимаю смысла говнять имеющийся инструментарий. Язык С++ далеко не идеален, но он достаточно хорош для решения большинства задач.
Он недостаточно хорош почти для любой задачи. Может в те времена когда Страуструп произнес эту фразу, она и была справедлива, но сейчас это не так.
DC>Вернемся к началу. Т.е. ты считаешь что С++ из области написания графических движков вытеснит другой инструмент типа Немерле или ОКамл?
Это дело времени. С++ если и останется, то как средство оптимизации узких мест.
DC> Поскольку требования к языку в статье и немало рендереров на ОКамле являют какую-то тенденцию. Когда это по твоему произойдет?
Срок может оказаться большим из-за косности мышления. Первые управляемые движки уже появились. Думаю, что через лет 5-10 можно ожидать, что народ перейдет на некую альтернативу. Нужда в ней назрела. Пока об этом говорят, только действительно дальновидные люди, но чем дальше, тем больше людей будет это понимать. Даже D и тот намного лучше чем С++.
Применение же дотнета в играх пока может сдерживаться тем фактом, что он доступен только на Xbox 360 и Windows. Но моно уже работает на туче платформ и если его подкрутят (и реализуют XNA), то проблема будет очень неплохим решением.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Низкоуровневая физика отчасти тоже уже переезжает на видеокарту.
Да, да, слышали. Только не на видеокарту, а на специальный физический ускоритель. Конкретную ссылку нет времени искать, могу только посоветовать по этому поводу порыться на ferra.ru. Где-то там промелькнула статья по поводу платы для ускорения физики.
Здравствуйте, dr.Chaos, Вы писали:
DC>Собственно, С++ хорош не для ГД, а для 3D движка. В ГД — купил движок, накрутил скриптов, заплатил художникам — игра готова.
Ну, так продемонстрируй хоть что-то что делало бы С++ предпочтительным для этих самых движков.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FDSC, Вы писали:
AF>>Самолет, которого нет, летает с нулевой скоростью. "Профессионалы", которые строят гипотетические самолеты, которые должны летать быстрее в 5 раз, но не летают вообще — это не профессионалы.
FDS>Может быть правильней сказать, что одни делают электровозы, а другие — самолёты? FDS>Конструктор электровоза самолёт не спроектирует, а наоборот — вполне.
Скорее нужно делить на игрушечные и настоящие. А уж электровозы там или самолёты... Настоящему индейцу, тьфу, программисту, ему — и самолёт, и корабль, и вёртолёт, и сеялка с вертикальным взлётом — программа и программа.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndreiF, Вы писали:
AF>Самолет, которого нет, летает с нулевой скоростью. "Профессионалы", которые строят гипотетические самолеты, которые должны летать быстрее в 5 раз, но не летают вообще — это не профессионалы.
А из чего следует, что их нет ? Я вроде такого не утверждал.
Если уж на то пошло...
Поставлена задача — к 2010 году обеспечить каждого пользователя собственным самолетом (прошу прощения, каждую контору "Рога и Копыта" собственым сайтом). Причем каждому нужен свой, серийное производство не годится. Професиональных самолетостроителей в таком количестве для этого взять негде. Поэтому реквизируются все, кто отличает шасси от крыла, и их сажают делать самолеты. Они их делают. Внешне это больше похоже на дельтаплан, но горючего он потребляет как космическая ракета, размеры имеет с Боинг, скорость — как у кукурузника, максимальная дальность — 100 километров. Но летает. Падает иногда, конечно, но это не страшно — его поднимают и опять запускают. Фирма довольна — теперь уполномоченный по копытам Шура Балаганов может летать в соседние деревни за копытами на этом самолете.
Ну а Боинг, Локхид и Туполев продолжают своими делами заниматься — изготовляют качественные самолеты. И с некоторым удивлением смотрят на это авиамоделирование
Здравствуйте, eugene0, Вы писали:
E>Та, в которой написано, что объем кода на скриптовых языках в современных играх больше, чем объекм кода на С++. Как правило
Там не написано, что он больше. Там написано, что он просто большой.
Здравствуйте, dr.Chaos, Вы писали: DC>Ооо. Ты открыл мне глаза
Я рад
DC>А ты себе представляешь сложность задачи? Унифицировать представление объектов в памяти на ВСЕХ возможных платформах.
Да, представляю. Благо решения есть. Велкам в управляемые среды. Java, .Net. DC>Кроме того к языку программирования это относится слабо. Кстати именно благодаря такому способу линковки С++ получил такое распространение и может использовать модули написанные на С, Fortran и т.д.
Ничего подобного. Не благодаря, а вопреки. Обратный пример: дотнет, с совершенно другим способом линковки, может использовать модули написанные на С, Fortran и т.д. И С++ тоже очень бы сильно выиграл, если бы автор вовремя спустился с небес на землю. DC>CORBA выросла примерно там же, только еще и с транспортом.
Я в курсе.
DC>Я вот не пойму что вы мне пытаетесь доказать? То что сборки под дот нет или компоненты Делфи лучше?
Нет, мы просто иллюстрируем тебе какую-то фатальную близорукость комитета в совершенно очевидных вещах.
DC>С чем ты споришь? Я понимаю что такая линковка — это тормозная и часто неудобная штука.
Не, пока не понимаешь. Проблема не в линковке. Ведь работают же компиляторы С++ поверх неё? Вот и нужно было уточнить спецификацию протокола. Безо всякого изменения механизма линковки — тем более, что комитет на линкер не влияет, а только на компиляторы. DC>Я понимаю что неунифицированное представление объектов — это проблемы совместимости платформ и компиляторов.НО!!! Простой как сибирский валенок механизм линковки, обеспечивает простоту реализации этого инструмента на любой платформе!! Мало того очень трудно сделать одинаково хорошее представление для микроконтроллера/PC/RISC-сервера/... Ты еще не забывай, что на специфических платформах нет ни шаблонов, ни множественного наследования и т.д. Т.е. создав единый стандарт представления — не угодили бы никому.
Всем бы прекрасно угодили. Это всё достижимо, нужно только понимать, что заниматься этим необходимо.
DC>Помимо всего прочего — кто мешает, собраться MC, GNU GCC и Comeau — и сделать стандарт представления и ему следовать??
Ну а комитету, который некоммерческий, кто мешает? Эрго: Хайнлайн прав.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndreiF, Вы писали:
E>>Та, в которой написано, что объем кода на скриптовых языках в современных играх больше, чем объекм кода на С++. Как правило
AF>Там не написано, что он больше. Там написано, что он просто большой.
Написано.
Позволю себе процитировать еще раз:
На самом деле, большая (по объему) часть современных игр пишется как раз на скриптах, в том числе и Питоне. Эта часть как правило больше, чем часть кода написанного на С++.
Ну так что, аргументы какие-нибудь будут или признаем что в процитированом ты ничего не смыслишь и написано оно в надежде на то, что оппонент в специфике отрасли не разбирается и возразить по этой причине не сможет?
Здравствуйте, konsoletyper, Вы писали:
АХ>>Низкоуровневая физика отчасти тоже уже переезжает на видеокарту.
K>Да, да, слышали. Только не на видеокарту, а на специальный физический ускоритель. Конкретную ссылку нет времени искать, могу только посоветовать по этому поводу порыться на ferra.ru. Где-то там промелькнула статья по поводу платы для ускорения физики.
Вот сайт производителя этого ускорителя
Только что-то пока ничего особенного с поддержкой этого ускорителя не вышло.
Во многом потому, что навороченная физика для большинства компьютерных игр довольно сомнительное приобретение.
Многие без нее обходятся и живут отлично.
Здравствуйте, eugene0, Вы писали:
E>Здравствуйте, konsoletyper, Вы писали:
АХ>>>Низкоуровневая физика отчасти тоже уже переезжает на видеокарту.
K>>Да, да, слышали. Только не на видеокарту, а на специальный физический ускоритель. Конкретную ссылку нет времени искать, могу только посоветовать по этому поводу порыться на ferra.ru. Где-то там промелькнула статья по поводу платы для ускорения физики.
E>Вот сайт производителя этого ускорителя E>Только что-то пока ничего особенного с поддержкой этого ускорителя не вышло. E>Во многом потому, что навороченная физика для большинства компьютерных игр довольно сомнительное приобретение. E>Многие без нее обходятся и живут отлично.
Потому что есть альтернативные решения для подобных числодробилок, например, PlayStation 3
Здравствуйте, eugene0, Вы писали:
E>Ну так что, аргументы какие-нибудь будут или признаем что в процитированом ты ничего не смыслишь и написано оно в надежде на то, что оппонент в специфике отрасли не разбирается и возразить по этой причине не сможет?
Я сказал то, что считаю верным. Если у тебя есть точная статистика — предъяви, и я соглашусь что был не прав.
Пока же я вижу только, что это ты пытаешься взять наглостью и переходишь на обсуждение личностей вместо обсуждения темы.
Здравствуйте, Sinclair, Вы писали:
S>Ничего подобного. Не благодаря, а вопреки. Обратный пример: дотнет, с совершенно другим способом линковки, может использовать модули написанные на С, Fortran и т.д.
Где можно посмотреть, как дотнет линкуется с модулями Fortran с платформ AIX или Solaris SPARC?
S> И С++ тоже очень бы сильно выиграл, если бы автор вовремя спустился с небес на землю.
Автор C++ сделал язык. Инструменты для этого языка писали совсем другие люди и конторы, которые при этом преследовали свои корысные интересы.
Пора бы уже понять, что C++ возник в совсем иных условиях. И достиг критической массы, после которой уже нельзя было ничего менять, C++ в условиях, когда принципа write once run everywhere в мейнстриме еще не было. Это потом уже богатая контора Sun учла опыт, в том числе и C++. И затратив N мегадолларов на разработку Java и еще M мегадолларов на ее раскрутку (причем не понятно насколько N меньше/больше M) поначалу получила медленного уродца, который более-менее оправился только к 99-му-2000-му. Вполне возможно, что на разработку C++ было потрачено даже меньше средств за все время его существования, чем на рекламу Java.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
E>>Копец начался еще раньше, когда появились различные и несовместимые между собой форматы OBJ-файлов статических библиотек. Даже в рамках одной платформы. Причем C++ не имел к этому никакого отношения.
VD>Согласен. Но Страуструп был в силах это изменить. Если не в первой версии, то хотя бы во второй. Тогда он уже имел вес и мог диктовать условия.
Не мог. Первые версии компилятора C++, даже с поддержкой шаблонов и исключений, были всего лишь препроцессорами, генерившими C-шный код. Далее работали штатные C-компиляторы и линкеры конкретной целевой платформы. Первый "родной" компилятор C++, Zortech C++, был написан в конце восьмидесятых для MS-DOS и не поддерживал самых продвинутых возможностей языка.
И я не очень представляю себе, как в 87-м или 89-м можно было выработать единый стандарт объектных файлов для 16-ти битовой MS-DOS с разными моделями памяти и 32-х битовыми мейнфреймами и RISC-рабочими станциями.
Тем более, что в отличии от нынешних времен, когда компиляторы менстримовых языков (Java и C#) принято раздавать бездвоздмездно (т.е. даром), в то время на продажах компиляторов деньги зарабатывали.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, eugene0, Вы писали:
E>>Ну так что, аргументы какие-нибудь будут или признаем что в процитированом ты ничего не смыслишь и написано оно в надежде на то, что оппонент в специфике отрасли не разбирается и возразить по этой причине не сможет?
AF>Я сказал то, что считаю верным. Если у тебя есть точная статистика — предъяви, и я соглашусь что был не прав.
Вообще-то, процитированный тезис выдвинул ты, тебе его и подтверждать. (Кстати, ты больше не отказываешься от него, как в предыдущем посте?) Судя по тому, что ты до сих пор этого не сделал, подтверждения у тебя нет, а тезис взят с потолка.
AF>Пока же я вижу только, что это ты пытаешься взять наглостью и переходишь на обсуждение личностей вместо обсуждения темы.
Да я что, я так Сижу на работе, пишу игру, почитываю форум в перерывах. Вижу, человек пишет вещи, не соответствующие действительности, данной мне в ощущениях, да еще гнобит тех, кто пытается его поправлять
Здравствуйте, eugene0, Вы писали:
E>Да я что, я так Сижу на работе, пишу игру, почитываю форум в перерывах. Вижу, человек пишет вещи, не соответствующие действительности, данной мне в ощущениях, да еще гнобит тех, кто пытается его поправлять
Здравствуйте, AndreiF, Вы писали:
E>>Да я что, я так Сижу на работе, пишу игру, почитываю форум в перерывах. Вижу, человек пишет вещи, не соответствующие действительности, данной мне в ощущениях, да еще гнобит тех, кто пытается его поправлять
А вот, ни в коем случае не в плане аргументации, просто как заметка.
Ради интереса посмотрел объем исходиков в проекте, над которым сейчас работаю (3D-шутер для PC, находится на завершающей стадии разработки).
Примерно 5 мегов исходников на C++, не считая сторонних библиотек, и 1 мег скриптов.
Реальность, данная мне в ощущениях
Здравствуйте, eugene0, Вы писали:
E>А вот, ни в коем случае не в плане аргументации, просто как заметка. E>Ради интереса посмотрел объем исходиков в проекте, над которым сейчас работаю (3D-шутер для PC, находится на завершающей стадии разработки). E>Примерно 5 мегов исходников на C++, не считая сторонних библиотек, и 1 мег скриптов. E>Реальность, данная мне в ощущениях
Кстати, вот была такая игра — "Казаки" (реал-тайм стратегия, отличается тем, что может держать одновременно на игровом поле 16т юнитов (первая версия, сейчас до 64т дошли, по-моему, не помню). Конкурентам такие цифры и не снились. Имхо, одна из лучших отечественных игр.
Я всего ее кода не видел, только маленький кусок, но что я увидел там: она была написала на С++, и более того, стратегии AI для игры за разные страны (там у разных стран разные строения, оружие, стоимость ресурсов и прочее, поэтому по-разному надо действовать) были тоже написаны на С++ и упрятаны в DLL-ки с названиями стран (т.е. если ты хотел играть против, скажем, Австрии, то просто подгружалась соответствующая DLL-ка и начинала против тебя играть). На моей тогдашней слабенькой машинке все летало.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>И AWT . Правда, насколько я понимаю, его уже мало кто использует.
AVK>Swing, вобще то, поверх AWT работает .
"Не флейма ради, а токмо чтобы ясность дополнительную внести"
Не совсем да, но и не совсем нет AWT использует нативные контролы (в терминологии Свинга "тяжеловесные компоненты"). Swing из нативных использует только окна, остальные компоненты делает сам(т.е. свинг отвечает полностью и за их отрисовку, и за событийную модель, и т.д.). Кстати, Swing — прекрасный пример, что "программы и библиотеки на Java — таааакие тормоза!" — не более чем миф.. Продуманной оптимизацией все издержки Java покрываються много раз.. На "тормознутость" интерфеса Свинговых прог никогда не жаловался (разве что какой умник не выносил длинные расчеты в отдельный поток, но тут уже /dev/hands).
С другой стороны, компоненты Swing наследуються от абстрактных классов AWT (пример), хотя, конечно, реализация у них "с ноля" и они не являються обёртками над AWT-компонентами. Исключение — JFrame, JDialog, JWindow, JApplet и другие им подобные, которые наследуються от конкретных классов AWT и используют их логику (т.е. создают нативные контролы).
Так что утверждение "Swing поверх AWT работает" скорее неверно, чем верно
DC>>А ты себе представляешь сложность задачи? Унифицировать представление объектов в памяти на ВСЕХ возможных платформах. S>Да, представляю. Благо решения есть. Велкам в управляемые среды. Java, .Net.
Когда вышел ARM, когда вышла Java и .Net? Мало того за эти 20 лет очень сильно поменялось железо. Так что в далеком 85, даже 91 было несколько иначе. Но как тогда, так и сейчас остается приоритетом именно портируемость на уровне исходников, а это уже не мало для платформы где нет VM, но есть компилятор С++.
DC>>Кроме того к языку программирования это относится слабо. Кстати именно благодаря такому способу линковки С++ получил такое распространение и может использовать модули написанные на С, Fortran и т.д. S>Ничего подобного. Не благодаря, а вопреки. Обратный пример: дотнет, с совершенно другим способом линковки, может использовать модули написанные на С, Fortran и т.д. И С++ тоже очень бы сильно выиграл, если бы автор вовремя спустился с небес на землю.
Какую землю? см. ответ eao197. Я думаю это тебе надо чуток спуститься на землю, или хотя бы вернуться в то время мыслью.
DC>>Я вот не пойму что вы мне пытаетесь доказать? То что сборки под дот нет или компоненты Делфи лучше? S>Нет, мы просто иллюстрируем тебе какую-то фатальную близорукость комитета в совершенно очевидных вещах.
У комитета есть четкие задачи и цели, которые были сформулированы еще во время его создания, вместо обвинений в близорукости почитай в чем они заключаются. Кроме того, для тебя они могут казаться очевидными, а для членов комитета очевидными и более нужными могут казаться другие вещи. Мало того есть инструменты удовлетворяющие твоим потребностям. Внимание вопрос: Зачем хаять комитет? За то что они решают другие проблемы? Почему ты решил что то, что тебе кажеться очевидным является необходимым в первую очередь? Если оно действительно так оформляй предложение в комитет, предлагай реализацию и т.п. Wellcome.
DC>>С чем ты споришь? Я понимаю что такая линковка — это тормозная и часто неудобная штука. S>Не, пока не понимаешь. Проблема не в линковке. Ведь работают же компиляторы С++ поверх неё? Вот и нужно было уточнить спецификацию протокола. Безо всякого изменения механизма линковки — тем более, что комитет на линкер не влияет, а только на компиляторы.
А компилятор видимо сам программы собирает ? Т.е. ты полагаешь, что проблемы с разной кодировкой имен это самая важна проблема совместимости? Да проше простого написать тулзу которая будет перекодировать манглинг различных компиляторов. Толь вот функцию я то вызвать смогу, а объект передать — уже нет.
DC>>Я понимаю что неунифицированное представление объектов — это проблемы совместимости платформ и компиляторов.НО!!! Простой как сибирский валенок механизм линковки, обеспечивает простоту реализации этого инструмента на любой платформе!! Мало того очень трудно сделать одинаково хорошее представление для микроконтроллера/PC/RISC-сервера/... Ты еще не забывай, что на специфических платформах нет ни шаблонов, ни множественного наследования и т.д. Т.е. создав единый стандарт представления — не угодили бы никому. S>Всем бы прекрасно угодили. Это всё достижимо, нужно только понимать, что заниматься этим необходимо.
Как? Ты представляешь себе различие в представлении компилятором множественного наследования, витртуального множественного наследования на разных компиляторах? Мало того для платформы которая работает в реальном времени, от этого производители компилятора вообще отказались, как и от обработки исключений, ради оптимизации и эффективности. Вот тебе и разница. Здесь нет компромисса, мало того это не противоречит основным идеям создателя С++. Совместимость С++ с С и стремление к равенству по скорости кода, причина такой популярности С++, но так же и причина его основных недостатков.
DC>>Помимо всего прочего — кто мешает, собраться MC, GNU GCC и Comeau — и сделать стандарт представления и ему следовать?? S>Ну а комитету, который некоммерческий, кто мешает? Эрго: Хайнлайн прав.
Никто. Внеси предложение . .
Думаю можно найти предложения которые решали бы эту проблему и посмотреть причины отказов. Полагаю, что они будут довольно вескими.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Стандарт С++ их и не регламентирует. Влад я думаю ты прекрасно знаешь принцип работы простейшего компоновщика, который заменяет имена функций и переменных, определенных в др единице компиляции, на их адрес. Не знаю есть ли стандарт или какие-то регламентирующие документы, если тебе это так важно могу поискать.
VD>Я то как раз знаю. Стандартов нет. Точнее у каждого свои. Борланд с МС еще как-то пытались кооперироваться, но толку было мало. Интел еще что-то там под МС косить пытается. Но те же GCC и VC не совместимы. Так что С++ — переносим только на уровне исходников.
Переносимость на уровне исходников, это и есть основной приоритет комитета.
DC>>А по поводу задач: задачи системного программирования: написание ОС, драйверов, компиляторов и т.п.
VD>ОС, драверы и темболее компиляторы пишутся на управляемых языках ничем не хуже, и даже лучше. И если первое пока, что находится в эксперементальной стадии, то компиляторы уже давно пишутся как на управляемых языках так и на неуправляемых функцинальных. Причем все кто пробовал использовать хорошие ФЯ для написания компиляторов находят, что это значительно удобнее нежели использовать С/С++ для этой цели.
VD>Так что это утверждение ошибочно. Это всего лишь самообман.
Влад в чем заключается мой самообман? В том, что ОС и Драйверы на управляемых языках экспериментальные? Или в том что на данный момент подавляющее большинство ОС и драйверов написано на С++ и/или С?
DC>> Хотя я думаю, что для написания компиляторов есть более подходящие инструменты, но я тут профан .
VD>Зато я кое что понимаю. С++ — это самый неудобный иструмент для этогою.
Т.е С++ говно полюбому? Да Влад это как мантра.
DC>> По поду прикладного ПО — вполне можно использовать С++ для написания ядра системы, а сверху накручивать прикладную логику каким-нибудь интерпретируемым языком, если грамотно сделать то будет и эффективность и скорость разработки.
VD>Остается вопрос зачем использовать С++ для того, что в несколько раз проще пишется на других языках? Я еще понимаю супер-корпорации вроде МС которые вполне могут позволить себе создать прототип, а потом приказать переписать его на С++ просто ради оптимизации. Но лишние мегабаксы есть только у 5-6 компаний в мире. Остальные живут в рамках жесточайшей конкурениции. И стло быть использовать С++ равносильно надеванию на себя гандикапа.
А если компания его использует уже 10-15 лет? Зачем при налаженном процессе переходить куда-то?
VD>>>А какая разница? К задачам это отношения не имеет. Средства могут различаться в зависимости от задач.
DC>>Тогда зачем спрашивал?
VD>Затем, что С++ практически всегда наихудший выбор. Вот и интересно с какой целью люди выбирают именно его? Не уж то так тяжело переучиваться?
Нет, просто на С++ тонны кода, возможности его не сильно хуже существующих управляемых языков. Понимаешь чтобы вытеснить С++ нужно предложить что-то намного лучшее. Для Java и .Net снижают стоимость разработки, и порог вхождения низкий, специалистов проще найти. Но только для некоторых областей!!! Где собственно С++ наиболее плох для применения.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Собственно, С++ хорош не для ГД, а для 3D движка. В ГД — купил движок, накрутил скриптов, заплатил художникам — игра готова.
VD>Ну, так продемонстрируй хоть что-то что делало бы С++ предпочтительным для этих самых движков.
Да хотя бы то, что возможностей у языка не меньше, а библиотек просто море + это проверенный инструмент.
А теперь все таки ответьте на мой вопрос. Что кардинально изменит Немерле или ОКамл. Не просто уменьшат многословность, а именно дадут?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>> Влад я сказал, что в MC не смогут разработать нормальный фреймворк для этого? Мало того после требований Висты, что-то у меня возникают сильные опасения, что "приемлемым по производительности" оно станет благодаря новым железкам, а не разработчикам в MC.
VD>Виста как и другой софт выпскаемый МС создается в рассчете на сегодняшнее зелезо. И это правильно, так как если у меня в машине 3D-акселератор с поддержкой DX 9.0, двух-ядерный процессор и 1-2 гига памяти, то глупо не задействовать это богатство для улучшения комфорта и удобства. Лично Вистой я очень доволен.
Влад, я мощьности на свой комп ставлю не для микрософта и ее ОС, а для того чтоб прикладное ПО там быстрее бегало.
[оффтопик]
Меня если честно удручает такое положение, я всерьез задумался над переходом на KUbuntu. Я понимаю что мне дал XP — большую стабильность, у меня он стоит уже 4 года, при этом синих экранов вообще не вспомню, подвисаний не больше 3-5 в год, учитывая то, что ставил я много всяких программ. Что мне даст виста? 3D интерфейс который мне не нужен? Какие принципиальные удобства я получу? Исправление собственных багов ценой моих денег и ресурсов моего компа?
[/оффтопик]
DC>>Рендерер = Движок ?
VD>По вычислетльной нагрузке это значительно больше. По сложности алгоритмов — тоже.
. А по сложности задачи? Движок в том или ином виде содержит в себе рендерер. Он правда заточен на другое.
DC>>>>Здорово, вот сошлась куча специалистов отрасли, потрындела 10 лет и в итоге выдала полный бред??
VD>>>Я говорю о конкретных требованиях конкретного человека. Блин, скачай ppt-у и пчитай. В его требованиях основными критериями являются надежность и безопасность. Ни шагу в этом направлении в новм стандарте нет.
DC>>Хм, ну С++ вобщем то универсальный язык,
VD>Ага. А в Киеве дядка. И что?
Сколько в комитете людей от компаний занимающих производством движков?
DC>>полагаю комитет руководствовался не пожеланиями конкретного человека. Верю что решения комитета могут не решить его проблем. Но утверждать, что улучшения которые появятся в 2009 году — бред, который ничего не изменит — глупо, по меньшей мере.
VD>Я не утверждал, что это бред. Я сказал, что С++ как раз то, что они исползуют и в чем находят (на мой взгляд совершенно обоснованно) море проблем. Интересно, что в качестве сравнения они использую C#, Java и Хаскель. Причем находят у всех языков ряд недостатков (впрочем как идостоинств).
Ты сказал, что стандарт ничего не изменит. Т.е. этот стандарт бред, несуразица
DC>>Сразу видно команда . Ты пойми Влад, я не против новых инструментов, если они появятся и решат проблемы в какой-то отрасли это просто здорово. Но просто не понимаю смысла говнять имеющийся инструментарий. Язык С++ далеко не идеален, но он достаточно хорош для решения большинства задач.
VD>Он недостаточно хорош почти для любой задачи. Может в те времена когда Страуструп произнес эту фразу, она и была справедлива, но сейчас это не так.
Достаточно хорош — это означает, что любую задачу можно решить используя высокоуровневые конструкции и современные приемы проектирования, при этом добиться максимальной эффективности.
DC>>Вернемся к началу. Т.е. ты считаешь что С++ из области написания графических движков вытеснит другой инструмент типа Немерле или ОКамл?
VD>Это дело времени. С++ если и останется, то как средство оптимизации узких мест.
DC>> Поскольку требования к языку в статье и немало рендереров на ОКамле являют какую-то тенденцию. Когда это по твоему произойдет?
VD>Срок может оказаться большим из-за косности мышления. Первые управляемые движки уже появились. Думаю, что через лет 5-10 можно ожидать, что народ перейдет на некую альтернативу. Нужда в ней назрела. Пока об этом говорят, только действительно дальновидные люди, но чем дальше, тем больше людей будет это понимать. Даже D и тот намного лучше чем С++.
Здорово . Только вот переход будет долгим не столько из-за дальновидности или еще чего-то, новый инструмент должен себя зарекомендовать, мало того чтобы вытеснить, он должен дать что-то что кардинально улучшит процесс разработки.
VD>Применение же дотнета в играх пока может сдерживаться тем фактом, что он доступен только на Xbox 360 и Windows. Но моно уже работает на туче платформ и если его подкрутят (и реализуют XNA), то проблема будет очень неплохим решением.
Возможно, время покажет.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Насчет линкинга — где посмотреть, не знаю. Но интероп в дотнете сделан очень тщательно. Подохреваю, что JNI на джаве должен работать с фортраном и на аиксе.
E>Автор C++ сделал язык. Инструменты для этого языка писали совсем другие люди и конторы, которые при этом преследовали свои корысные интересы.
Что именно ты имеешь в виду под инструментами? Линкер? Он не для этого языка. Ок, я согласен с тем, что автор свою роль сыграл. Но комитет почему-то не сделал столь очевидных шагов. И это притом, что язык позиционируется как системный! Т.е. в нем предусмотрена масса платформенных фич, типа моделей памяти (кто еще помнит, что это такое?) и битовых полей.
Почему при этом комитет не удосужился стандартизовать такую простую вещь, как манглинг — я не понимаю.
E>Пора бы уже понять, что C++ возник в совсем иных условиях. И достиг критической массы, после которой уже нельзя было ничего менять, C++ в условиях, когда принципа write once run everywhere в мейнстриме еще не было.
Ну почему нельзя-то? Ведь меняли же. Язык бурно развивался. Это не ошибка, это намеренный саботаж. E>Это потом уже богатая контора Sun учла опыт, в том числе и C++. И затратив N мегадолларов на разработку Java и еще M мегадолларов на ее раскрутку (причем не понятно насколько N меньше/больше M) поначалу получила медленного уродца, который более-менее оправился только к 99-му-2000-му. Вполне возможно, что на разработку C++ было потрачено даже меньше средств за все время его существования, чем на рекламу Java.
Это никак не оправдывает некомпетентность комитета.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Насчет линкинга — где посмотреть, не знаю. Но интероп в дотнете сделан очень тщательно. Подохреваю, что JNI на джаве должен работать с фортраном и на аиксе.
Дык и работает, только вот фортрановский модуль на AIX-е нигде кроме AIX-а работать не будет. Да и работать будет, потому что JNI на AIX-е реализуется через нативные AIX-овские коды. В таких условиях и к C++ модули C/Fortran спокойно линкуются.
E>>Автор C++ сделал язык. Инструменты для этого языка писали совсем другие люди и конторы, которые при этом преследовали свои корысные интересы. S>Что именно ты имеешь в виду под инструментами? Линкер?
И компилятор. C++ные компиляторы денег стоили, а некоторые и сейчас стоят (сами компиляторы, даже без IDE).
S>Почему при этом комитет не удосужился стандартизовать такую простую вещь, как манглинг — я не понимаю.
Боюсь, что одного манглинга мало. К тому же, к моменту начала стандартизации (89-90 гг) уже был большой зоопарк разных компиляторов с собственными правилами манглинга. Заставить их тогда что-то переделывать было вряд ли возможно, ведь тогда могли пострадать клиенты этих производителей компиляторов (ведь пришлось бы переходе на новые версии перекомпилировать весь ранее написанный код, а может еще и править его).
E>>Пора бы уже понять, что C++ возник в совсем иных условиях. И достиг критической массы, после которой уже нельзя было ничего менять, C++ в условиях, когда принципа write once run everywhere в мейнстриме еще не было. S>Ну почему нельзя-то? Ведь меняли же. Язык бурно развивался. Это не ошибка, это намеренный саботаж.
Изменений в языке, которые бы нарушали совместимость с предудущим кодом было не так уж и много. В основном язык обрастал возможностями.
S>Это никак не оправдывает некомпетентность комитета.
Не могу судить о комитете. Более того, я сам придерживаюсь мнения, что комитеты вряд ли могут привести к чему-нибудь хорошему. Но, по крайней мере, в одной области комитет уже сыграл свою положительную роль -- стандарт хоть как-то обеспечивает переносимость C++ программ в исходных текстах между платформами и компиляторами. Что для языка, с самого начала жизни которого различных компиляторов которого было множество, означало очень и очень многое.
Большего от комитета я и сам не жду. Имхо, самые лучшие черты C++ приобрел, когда им занимались отдельные конкретные люди -- Страуструп, как дизайнер языка, и Степанов, как автор STL.
Я просто прошу воздерживаться от резких высказываний в адрес автора C++, поскольку мы сейчас находимся совсем в других условиях. Да и не сделал никто из нас ничего настолько же значимого, чтобы иметь моральное право брать на себя роль судьи.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, dr.Chaos, Вы писали:
DC>Когда вышел ARM, когда вышла Java и .Net? Мало того за эти 20 лет очень сильно поменялось железо.
За какие 20 лет? С++ в современном виде едва ли не моложе джавы. Когда в него ввели частичную специализацию шаблонов?
DC>Так что в далеком 85, даже 91 было несколько иначе. Но как тогда, так и сейчас остается приоритетом именно портируемость на уровне исходников, а это уже не мало для платформы где нет VM, но есть компилятор С++.
Приоритетом должны оставаться потребности пользователей, а не стремление к прекрасному.
DC>Какую землю? см. ответ eao197. Я думаю это тебе надо чуток спуститься на землю, или хотя бы вернуться в то время мыслью.
В то время — это в какое? Когда был принят актуальный стандарт С++? Сколько еще нужно ждать, чтобы комитет наконец задумался о вопросах интеропа? Бред какой-то. Газотурбинный двигатель изобрели, а до щеколды не додумались.
DC>У комитета есть четкие задачи и цели, которые были сформулированы еще во время его создания, вместо обвинений в близорукости почитай в чем они заключаются. DC>Кроме того, для тебя они могут казаться очевидными, а для членов комитета очевидными и более нужными могут казаться другие вещи. Именно поэтому я и ушел с плюсов — разошелся, видишь ли, в целях и задачах с комитетом.
Да, кстати, пользуясь случаем передаю привет от Хайнлайна комитету W3C.
DC>Мало того есть инструменты удовлетворяющие твоим потребностям. Внимание вопрос: Зачем хаять комитет? За то что они решают другие проблемы?
Конечно.
DC>А компилятор видимо сам программы собирает ? Т.е. ты полагаешь, что проблемы с разной кодировкой имен это самая важна проблема совместимости? Да проше простого написать тулзу которая будет перекодировать манглинг различных компиляторов. Толь вот функцию я то вызвать смогу, а объект передать — уже нет.
Вот именно, только почему-то комитет вообще не счел нужным упомянуть о такой тулзе или подумать о том, какая информация может быть ей нужна. Передачу объектов тоже можно было сделать вполне человеческим образом — мне, если честно, лень тут в двух строках делать работу, с которой не смогла справиться Вся Королевская Рать за двадцать лет. Просто им хотелось заниматься не этим.
DC>Как? Ты представляешь себе различие в представлении компилятором множественного наследования, витртуального множественного наследования на разных компиляторах?
Конечно представляю. Я вот только не могу понять одного — почему нельзя было стандартизовать формат метаданных для интеропа, оставив возможность внутренней реализации для повышения производительности? Это же ничему не противоречит. DC>Мало того для платформы которая работает в реальном времени, от этого производители компилятора вообще отказались, как и от обработки исключений, ради оптимизации и эффективности.
Производители компилятора — вообще отдельные люди. DC>Вот тебе и разница. Здесь нет компромисса, мало того это не противоречит основным идеям создателя С++. Совместимость С++ с С и стремление к равенству по скорости кода, причина такой популярности С++, но так же и причина его основных недостатков.
Да ничего подобного. С++ не стремился к равенству по скорости; лозунг С++ — не надо платить за то, чем не пользуешься. Поэтому вполне в рамках концепции была бы стандартизация интеропа, пусть даже она и приводила бы к потерям производительности при кросс-компиляторной линковке. Главное — что а) эта линковка была бы возможна и б) производительность в случае ее отсутствия не страдала бы.
Причем заметь — это мы обсудили одну только маахонькую фичу — компонентность, а ведь это не она одна. То, что комитет наплевал на возможность поставлять библиотеки в кросс-компиляторном бинарном виде, это только их вина. Ты упорно отказываешься видеть, что нету в С++ никакой компонентности. И уже 15 лет комитет страдает фигнёй от избытка интеллекта. DC>Никто. Внеси предложение . .
Да у них этих предложений тонны.
DC>Думаю можно найти предложения которые решали бы эту проблему и посмотреть причины отказов. Полагаю, что они будут довольно вескими.
Мне всё равно, насколько вески эти причины. Хотя скорее всего причина ровно одна — отсутствие консенсуса. См. Р. Хайнлайна.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, dr.Chaos, Вы писали: DC>А теперь все таки ответьте на мой вопрос. Что кардинально изменит Немерле или ОКамл. Не просто уменьшат многословность, а именно дадут?
А кроме уменьшения многословности ничего дать-то и нельзя. См. Тезис Чёрча. Впрочем, с учетом константности плотности ошибок ничего, кроме краткости, и не требуется.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, jazzer, Вы писали:
J>Кстати, вот была такая игра — "Казаки" (реал-тайм стратегия, отличается тем, что может держать одновременно на игровом поле 16т юнитов (первая версия, сейчас до 64т дошли, по-моему, не помню). Конкурентам такие цифры и не снились. Имхо, одна из лучших отечественных игр.
J>Я всего ее кода не видел, только маленький кусок, но что я увидел там: она была написала на С++, и более того, стратегии AI для игры за разные страны (там у разных стран разные строения, оружие, стоимость ресурсов и прочее, поэтому по-разному надо действовать) были тоже написаны на С++ и упрятаны в DLL-ки с названиями стран (т.е. если ты хотел играть против, скажем, Австрии, то просто подгружалась соответствующая DLL-ка и начинала против тебя играть). На моей тогдашней слабенькой машинке все летало.
Предполагаю, что такой подход использовали именно из-за того, что там такое огромное кол-во юнитов на поле одновременно. Возможно, скриптовый движок не потянул такое кол-во выполняемых одновременно скриптов.
IMHO если юнитов поменьше (у нас, например, обычно не больше 20), то лучше все-таки писать скрипты. Тогда можно будет переложить работу с программистов на дизайнеров миссий, что во многих отношениях правильно.
Здравствуйте, VladD2, Вы писали:
DC>> Влад я сказал, что в MC не смогут разработать нормальный фреймворк для этого? Мало того после требований Висты, что-то у меня возникают сильные опасения, что "приемлемым по производительности" оно станет благодаря новым железкам, а не разработчикам в MC.
VD>Виста как и другой софт выпскаемый МС создается в рассчете на сегодняшнее зелезо.
Сегодняшнее железо бывает разным, и скажем, на ноутбук, где проблема времени жизни от аккумулятора является одной из важнейших не имеет смысла ставит операционную систему которая будет впустую потреблять много энергии.
VD> И это правильно, так как если у меня в машине 3D-акселератор с поддержкой DX 9.0, двух-ядерный процессор и 1-2 гига памяти, то глупо не задействовать это богатство для улучшения комфорта и удобства.
Глупо не иметь возможности задействовать это богатство. Но так же бессмысленно требовать DX 9.0 видеокарту, двух-ядерный процессор и 1-2 гига памяти на офисном компе у секретарши на котором в основном читают почту и серфят Инет.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, dr.Chaos, Вы писали: DC>>А теперь все таки ответьте на мой вопрос. Что кардинально изменит Немерле или ОКамл. Не просто уменьшат многословность, а именно дадут? S>А кроме уменьшения многословности ничего дать-то и нельзя. См. Тезис Чёрча. Впрочем, с учетом константности плотности ошибок ничего, кроме краткости, и не требуется.
FR,
DC>>>А теперь все таки ответьте на мой вопрос. Что кардинально изменит Немерле или ОКамл. Не просто уменьшат многословность, а именно дадут? S>>А кроме уменьшения многословности ничего дать-то и нельзя. См. Тезис Чёрча. Впрочем, с учетом константности плотности ошибок ничего, кроме краткости, и не требуется.
FR>Все бежим изучать J?
Вывод неправильный. Видел программы для J которые используют OpenGL? Чудес не бывает: любая достаточно сложная программа на J так же будет использовать некоторый API, а следовательно там уже не получишь такой краткости, как на ядре. Подобные API просто предоставляют список методов, которые можно подёргать.
Мне думается, в выигрыше язык, который обладает наиболее продвинутым клеем (просто "дёрнуть функцию" недостаточно) и возможностями по созданию библиотек которые предоставляют такие клеящие поверхности.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, dr.Chaos, Вы писали: DC>>А теперь все таки ответьте на мой вопрос. Что кардинально изменит Немерле или ОКамл. Не просто уменьшат многословность, а именно дадут? S>А кроме уменьшения многословности ничего дать-то и нельзя. См. Тезис Чёрча. Впрочем, с учетом константности плотности ошибок ничего, кроме краткости, и не требуется.
Хм, т.е. все улучшения которые дают Немерл и Окамл это уменьшение многословности? Мда уж что-то тогда индустрия на месте топчется получается, только шаги красивше и меньше выходят.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, dr.Chaos, Вы писали:
DC>Хм, т.е. все улучшения которые дают Немерл и Окамл это уменьшение многословности? Мда уж что-то тогда индустрия на месте топчется получается, только шаги красивше и меньше выходят.
Ну ИМХО Асм -> С тоже в значительной мере уменьшение многословности...
Здравствуйте, eao197, Вы писали:
E>Не мог. Первые версии компилятора C++, даже с поддержкой шаблонов и исключений, были всего лишь препроцессорами, генерившими C-шный код.
Шаблоны и исключения появились намного позже, уже в 90-х.
E> Далее работали штатные C-компиляторы и линкеры конкретной целевой платформы. Первый "родной" компилятор C++, Zortech C++, был написан в конце восьмидесятых для MS-DOS и не поддерживал самых продвинутых возможностей языка.
Это каких?
E>И я не очень представляю себе, как в 87-м или 89-м можно было выработать единый стандарт объектных файлов для 16-ти битовой MS-DOS с разными моделями памяти и 32-х битовыми мейнфреймами и RISC-рабочими станциями.
А мозг на что человеку даден? Нужно было подумать им немного.
E>Тем более, что в отличии от нынешних времен, когда компиляторы менстримовых языков (Java и C#) принято раздавать бездвоздмездно (т.е. даром), в то время на продажах компиляторов деньги зарабатывали.
Вот он корень зла!
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Глупо не иметь возможности задействовать это богатство. Но так же бессмысленно требовать DX 9.0 видеокарту, двух-ядерный процессор и 1-2 гига памяти на офисном компе у секретарши на котором в основном читают почту и серфят Инет.
Пусть секретарша не включает Aero и ей не понадобится мощная видеокарта. Насчёт 2-х ядерного камня у меня тоже сомнения. А гиг памяти — мелочь.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, dr.Chaos, Вы писали:
DC>>Когда вышел ARM, когда вышла Java и .Net? Мало того за эти 20 лет очень сильно поменялось железо. S>За какие 20 лет? С++ в современном виде едва ли не моложе джавы. Когда в него ввели частичную специализацию шаблонов?
С++ придумали практически в 85-86 годах, реализовывали долго. Со времен ARM ничего толком не изменилось из того что касается маглинга.
DC>>Так что в далеком 85, даже 91 было несколько иначе. Но как тогда, так и сейчас остается приоритетом именно портируемость на уровне исходников, а это уже не мало для платформы где нет VM, но есть компилятор С++. S>Приоритетом должны оставаться потребности пользователей, а не стремление к прекрасному.
Приоритетами занимаются пользователи, которые сидят в комитете,
DC>>Какую землю? см. ответ eao197. Я думаю это тебе надо чуток спуститься на землю, или хотя бы вернуться в то время мыслью. S>В то время — это в какое? Когда был принят актуальный стандарт С++? Сколько еще нужно ждать, чтобы комитет наконец задумался о вопросах интеропа? Бред какой-то. Газотурбинный двигатель изобрели, а до щеколды не додумались.
Принят был в 99, но видимо толи решения предлагаемые не всех устраивают, толи производители компиляторов сознательно тормозят эти процессы.
Это не щеколда, это если вдруг понадобился двигатель который способен работать и на керосине, и на спирте и на метане, причем практически без изменений КПД.
DC>>У комитета есть четкие задачи и цели, которые были сформулированы еще во время его создания, вместо обвинений в близорукости почитай в чем они заключаются. DC>>Кроме того, для тебя они могут казаться очевидными, а для членов комитета очевидными и более нужными могут казаться другие вещи. S> Именно поэтому я и ушел с плюсов — разошелся, видишь ли, в целях и задачах с комитетом. S>Да, кстати, пользуясь случаем передаю привет от Хайнлайна комитету W3C.
DC>>Мало того есть инструменты удовлетворяющие твоим потребностям. Внимание вопрос: Зачем хаять комитет? За то что они решают другие проблемы? S>Конечно.
DC>>А компилятор видимо сам программы собирает ? Т.е. ты полагаешь, что проблемы с разной кодировкой имен это самая важна проблема совместимости? Да проше простого написать тулзу которая будет перекодировать манглинг различных компиляторов. Толь вот функцию я то вызвать смогу, а объект передать — уже нет. S>Вот именно, только почему-то комитет вообще не счел нужным упомянуть о такой тулзе или подумать о том, какая информация может быть ей нужна. Передачу объектов тоже можно было сделать вполне человеческим образом — мне, если честно, лень тут в двух строках делать работу, с которой не смогла справиться Вся Королевская Рать за двадцать лет. Просто им хотелось заниматься не этим.
Сделать передачу объекта м-ду конкретными платформами и компиляторами действительно несложно . Ты это в общем виде сделай да так чтоб всех устраивало. Это отдельный стандарт по объемам ИМХО, который к имеет прямое отношение к реализации компиляторов.
DC>>Как? Ты представляешь себе различие в представлении компилятором множественного наследования, витртуального множественного наследования на разных компиляторах?
S>Конечно представляю. Я вот только не могу понять одного — почему нельзя было стандартизовать формат метаданных для
интеропа, оставив возможность внутренней реализации для повышения производительности? Это же ничему не противоречит.
Потому как это скорее работа библиотеки. CORBA вполне себе справляется.
DC>>Мало того для платформы которая работает в реальном времени, от этого производители компилятора вообще отказались, как и от обработки исключений, ради оптимизации и эффективности. S>Производители компилятора — вообще отдельные люди. DC>>Вот тебе и разница. Здесь нет компромисса, мало того это не противоречит основным идеям создателя С++. Совместимость С++ с С и стремление к равенству по скорости кода, причина такой популярности С++, но так же и причина его основных недостатков. S>Да ничего подобного. С++ не стремился к равенству по скорости; лозунг С++ — не надо платить за то, чем не пользуешься. Поэтому вполне в рамках концепции была бы стандартизация интеропа, пусть даже она и приводила бы к потерям производительности при кросс-компиляторной линковке. Главное — что а) эта линковка была бы возможна и б) производительность в случае ее отсутствия не страдала бы.
Всегда стремился, хотя бы потому как сначала работал просто как препроцессор для Си. Стандарт интеропа по времени затраченному на его определение занял бы ИМХО даже больше времени, чем собственно стандарт языка.
S>Причем заметь — это мы обсудили одну только маахонькую фичу — компонентность, а ведь это не она одна. То, что комитет наплевал на возможность поставлять библиотеки в кросс-компиляторном бинарном виде, это только их вина. Ты упорно отказываешься видеть, что нету в С++ никакой компонентности. И уже 15 лет комитет страдает фигнёй от избытка интеллекта.
Страуструп данную возможность упоминает, но что там с ее реализацией — хз, видимо не нашлось решения, которое устроило бы всех.
DC>>Никто. Внеси предложение . . S>Да у них этих предложений тонны.
DC>>Думаю можно найти предложения которые решали бы эту проблему и посмотреть причины отказов. Полагаю, что они будут довольно вескими. S>Мне всё равно, насколько вески эти причины. Хотя скорее всего причина ровно одна — отсутствие консенсуса. См. Р. Хайнлайна.
Комитет, на данный момент лучший выбор из всех возможных.
Мне непонятна ваша страсть — ругать отвертку за то, что она не заточена под вашу руку, ну хоть убей — не пойму. Мало того убеждать других, что отвертка заточенная под вашу руку подойдет всем. Люди перестаньте хаять довольно популярный инструмент причем эффективности и возможностей ему занимать не надо. Если он вас не устраивает измените его, внесите предложение в комитет добейтесь чтобы его приняли или просто возьмите/сделайте другой. Dixi.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, Mirrorer, Вы писали:
M>Здравствуйте, dr.Chaos, Вы писали:
DC>>Хм, т.е. все улучшения которые дают Немерл и Окамл это уменьшение многословности? Мда уж что-то тогда индустрия на месте топчется получается, только шаги красивше и меньше выходят.
M>Ну ИМХО Асм -> С тоже в значительной мере уменьшение многословности...
Ну уж нет, Си явно выражал концепцию структурного программирования, т.е. вводил новые абстракции что ли.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, dr.Chaos, Вы писали:
M>>Ну ИМХО Асм -> С тоже в значительной мере уменьшение многословности...
DC>Ну уж нет, Си явно выражал концепцию структурного программирования, т.е. вводил новые абстракции что ли.
Не довелось застать перехода с Асма на С. Поэтому могу только предполагать что первые версии С недалеко от фортрана были, то бишь банальное упрощение кода. Это тоже имхо, могу ошибаться. Если у кого есть более точные данные прошу кинуть ссылкой.
И далее. Почему-то мне кажется что структурно можны было писать и на Асме(допустим макроподстановками). Равно как и неструктурно на С.
... << RSDN@Home 1.2.0 Marilyn Manson — Coma Black >>
Здравствуйте, Mirrorer, Вы писали:
M>Здравствуйте, dr.Chaos, Вы писали:
M>>>Ну ИМХО Асм -> С тоже в значительной мере уменьшение многословности...
DC>>Ну уж нет, Си явно выражал концепцию структурного программирования, т.е. вводил новые абстракции что ли.
M>Не довелось застать перехода с Асма на С. Поэтому могу только предполагать что первые версии С недалеко от фортрана были, то бишь банальное упрощение кода. Это тоже имхо, могу ошибаться. Если у кого есть более точные данные прошу кинуть ссылкой.
M>И далее. Почему-то мне кажется что структурно можны было писать и на Асме(допустим макроподстановками). Равно как и неструктурно на С.
Это все верно, только я прошу чтоб мне привели те кардинальные изменения, которые упростят работу с алгоритмами в алгоритмах оптимизации отображения сцены или хотя бы в других алгоритмах используемых в движках. Я думаю ничего кардинального со времен процедурной модели не появилось . Я конечно не ас в ФП, но мне все-таки кажеться, что в этом плане ничего принципиально не измениться.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Sinclair wrote: > Оказывается, что очень большой вес играет именно последний уровень. Вон > — почитай отзывы на конкурсах по разработке уровней. Банальное > дописывание скрипта, который закрывает двери за героем может ускорить > игру в два-три раза. Потому как главное в 21 веке — не выплевывание > пикселов со скоростью шины, а аккуратное отсечение лишних треугольников
Эта проблема была решена давным давно с помощью BSP/Octree и их
комбинаций
Я немного помогал писать игрушку с движком Ogre3d — там самая сложность
как раз в обсчете геометрии. То есть в оптимизации рисования теней,
анимации моделей и тому подобного. Каких-то суперкрутых алгоритмов с
суперкрутым паттерн-матчингом в десять уровней вложенности тут нет, но
есть огромное количество достаточно сложноструктурированых данных. Над
этими данными часто работают абсолютно скучные алгоритмы, представляющие
собой скопление формул.
GC на таких структурах тоже часто очень быстро сдыхает — ну не живет он
с сильносвзяными изменяющимися данными.
Я где-то приводил пример структуры геометрических данных из моей
(неигровой) программы, сейчас вот только найти ее не могу — RSDN глючит
Вот для игровых скриптов что-то типа Nemerle рулило бы, да собственно
там сейчас и так уже вполне неплохой LUA/Python используют.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
VD>>>А какой у тебя опыт написания переносимых программ на других языка?
Ш>>Речь шла о C++. Причем тут другие языки?
VD>Не допускаешь, что то что ты считаешь нормальным в сравнении с другим языком может оказаться ужасно сложно и медленно?
Нет, я допускаю, что ты пытаешься подменить предмет обсуждения.
VD>Другими словами, не допускаешь, что делов в твоей неверной оценке?
Я, видимо, плохо знаю русский язык. Во всяком случае, смысл этого предложения я не уловил.
Здравствуйте, eugene0, Вы писали:
E>Вот сайт производителя этого ускорителя E>Только что-то пока ничего особенного с поддержкой этого ускорителя не вышло. E>Во многом потому, что навороченная физика для большинства компьютерных игр довольно сомнительное приобретение. E>Многие без нее обходятся и живут отлично.
Мнение из середины 90-x:
Только что-то пока ничего особенного с поддержкой этого ускорителя не вышло.
Во многом потому, что навороченная 3D графика для большинства компьютерных игр довольно сомнительное приобретение.
Многие без нее обходятся и живут отлично.
Здравствуйте, IT, Вы писали:
E>>Не мог. Первые версии компилятора C++, даже с поддержкой шаблонов и исключений, были всего лишь препроцессорами, генерившими C-шный код.
IT>Шаблоны и исключения появились намного позже, уже в 90-х.
Необходимость поддержки параметризованных типов, исключений и множественного наследования в C++ была описана Страуструпом в 1986 г. в статье "What is Object-Oriented Programming". Затем, в мае 1990-го вышла книга The Annotated C++ Reference Manual (ARM) в которой механизм шаблонов и исключений был описан. Вот, что об этом говорит сам Страуструп:
Итак, в ARM были представлен следующие возможности:
* все, что вошло в версию 2.0;
* шаблоны;
* исключения;
* вложенные классы;
* раздельная перегрузка префиксных и постфиксных операций ++ и --;
* volatile;
* локальные статические массивы.
Все описанные в ARM возможности, кроме исключений, получили широкое распространение вместе с версией Cfront 3.0 в октябре 1991 г. Полная реализация возможностей, упомянутых в ARM, впервые появилась в компиляторах фирм DEC и IBM в начале 1992.
(Дизайн и эволюция языка C++, 2-е издание).
А Cfront, в котором шаблоны появились впервые, был как раз препроцессором.
И, если не ошибаюсь, то ли DEC-овский, то ли IBM-овский компилятор был так же препроцессором.
E>> Далее работали штатные C-компиляторы и линкеры конкретной целевой платформы. Первый "родной" компилятор C++, Zortech C++, был написан в конце восьмидесятых для MS-DOS и не поддерживал самых продвинутых возможностей языка.
IT>Это каких?
Как раз шаблонов и исключений Я сталкивался с Zortech C++ годах в 92/93-м -- там этого не было.
E>>И я не очень представляю себе, как в 87-м или 89-м можно было выработать единый стандарт объектных файлов для 16-ти битовой MS-DOS с разными моделями памяти и 32-х битовыми мейнфреймами и RISC-рабочими станциями.
IT>А мозг на что человеку даден? Нужно было подумать им немного.
Я вот не могу себе представить другого способа для этого, кроме компиляции не в объектный код, а в код какой-нибудь виртуальной машины. С последующей трансляций в конкретный нативный код.
Однако, это совсем не простая задача. Smalltalk-у для этого потребовалось ой как много времени.
К тому же это была бы совсем другая история.
Если мне не изменяет память, то в Borland-овских компиляторах вообще можно было умудрится слинковать в один проект obj-файлы, скомпилированные в разных моделях памяти (например, small и large), а затем долго выяснять, почему же программа странно себя ведет. Если уж одна фирма в своих объектных файлах разобраться не могла, то что уже говорить об общем формате для конкурирующих фирм.
E>>Тем более, что в отличии от нынешних времен, когда компиляторы менстримовых языков (Java и C#) принято раздавать бездвоздмездно (т.е. даром), в то время на продажах компиляторов деньги зарабатывали.
IT>Вот он корень зла!
Да, деньги способны испортить все, что угодно.
Кстати, не поэтому ли Sun придушила MS Java в зародыше?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, dr.Chaos, Вы писали:
M>>Не довелось застать перехода с Асма на С. Поэтому могу только предполагать что первые версии С недалеко от фортрана были, то бишь банальное упрощение кода. Это тоже имхо, могу ошибаться. Если у кого есть более точные данные прошу кинуть ссылкой.
это ведь не одноразовый процесс. ЯП развиввлись десятилетиями, обрастая всё новыми возможностями и лишаясь старых. например, в фортране не было зарезервированных слов, а пробелы в идентификаторах игнорировались. говорят, из-за этого в одной программе цикл 'do' превратился в писванивание (там была банальная опечатка, которую компайлер не смог заметить) и Вояджер не долетел до Венеры
M>>И далее. Почему-то мне кажется что структурно можны было писать и на Асме(допустим макроподстановками). Равно как и неструктурно на С.
это ещё что. у борладнда в асме есть ООП расширения у приницпе, спец. языки лишь *облегчают* использование выбранной методологии программирования
DC>Это все верно, только я прошу чтоб мне привели те кардинальные изменения, которые упростят работу с алгоритмами в алгоритмах оптимизации отображения сцены или хотя бы в других алгоритмах используемых в движках. Я думаю ничего кардинального со времен процедурной модели не появилось . Я конечно не ас в ФП, но мне все-таки кажеться, что в этом плане ничего принципиально не измениться.
преимущества Хаскела — очень строгая типизация, отлавливающая большинство ошибок с типами, и лёгкость конструирования алгоримтов из составных частей. я не представляю себе потребности игр, но вот к примеру печать простых чисел:
main = print primes
primes = 2:filter is_prime [3,5..]
is_prime n = all (\p-> n `mod` p /= 0) (takeWhile (\p-> p*p<=n) primes)
напиши это на своём родном языке
или вот это:
-- |this function finds last space in String within 80-char boundary
len_f = last . filter (<80) . findIndices (==' ')
впрочем, это только "гарики". настоящая мощь наступает когда ты передаёшь функции/процедуры куда тебе нужно, строишь из этих входных данных более сложные функции/процедуры и передаёшь их дальше. к сожалению, примеры использования этого довольно велики и их будет сложно объяснить здесь
вот напоследок ещё один небольшой алгоритм. суть его в том, что есть а-ля RAR список номеров сбойных секторов в архиве и его надо разделить на две части — секторы, чей номер по модулю rec_sectors уникален (их можно восстановить), от тех, которые накладываются друг на друга:
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, eugene0, Вы писали:
E>>Вот сайт производителя этого ускорителя E>>Только что-то пока ничего особенного с поддержкой этого ускорителя не вышло. E>>Во многом потому, что навороченная физика для большинства компьютерных игр довольно сомнительное приобретение. E>>Многие без нее обходятся и живут отлично.
K> Мнение из середины 90-x:
<поскипал цитату>
Вообще-то это уже совершенный оффтопик, но все же отвечу. Думаю, модераторы перенесут ветку в игры, если посчитают нужным.
Я имел в виду не обязательно железно ускоряемую физику, а вообще любую. Мы тут пытаемся использовать тот самый PhysX, на который я кидал ссылку. Так вот, если бы мне сейчас довелось начинать делать игру заново, я бы сильно подумал, стоит ли использовать ее вообще. Дело в том, что физический движок весьма сложен в настройке, да и багов в нем предостаточно. Время, которое мы потратили на борьбу с ним, ужасает. А между тем, что мы с него имеем:
1) Collision detection, с помощью которой выясняем, может ли игрок идти, или он уткнулся в стену. Без этого, конечно, обойтись сложно, но есть математические пакеты, позволяющие получить такую функциональность без включения в проект полновесного физического движка
2) Динамика разнообразных твердых тел. У нас она реально нужна только для метательного оружия типа гранат. Плюс всякие предметы, которые мешаюся у игрока под ногами и прикольно разлетаются, если рядом что-нибудь взорвалось. Гранаты — это, конечно, проблема, без остального можно обойтись.
3) Рэгдолл — то, что происходит с человечком, когда он умирает. Актуально, когда нужно красиво упасть из окна или повиснуть на заборе. В остальных случаях можно просто наделать больше красивых анимаций смерти. Впрочем, падение из окна можно тоже анимировать.
Собственно, это все. Есть еще всякая экзотика типа честной (почти) льющейся воды или честно развевающихся тряпочек, без которых в большинстве случаев тоже можно обойтись.
Еще, кстати, неслабый удар по производительности вся эта физика.
Между тем, есть отличные игры, которые без нее неплохо обходятся. Посмотрите, например, на Call of Duty.
Впрочем, не исключаю, что я неправ и недооцениваю мощь игровой физики и ускорителей.
Допускаю, что могу быть не вполне объективным, очень уж я с ней намучался
Здравствуйте, Cyberax, Вы писали:
>> Нафига? Вон, Цивилизация 4 на питоне фактически написана, только движок на C++. C>Поэтому CivIV всеми и считается жутко тормозящей
Это утверждение совершенно точно неверно, потому что вот он я — которй не считает ее жутко тормозящей
А я ведь еще и не являюсь "правильным геймером" и не стремлюсь к постоянному апгрейду компа, а когда и апгрейд делаю — опять же не беру Самое-самое, а укладываюсь в бюджетные решниея...
Ну и из узкого круга тех, с кем общался про Civ IV, как-то не слышал чтобы жаловались на тормознутость..
Ах да — когда только вышла — была какая-то трабла, чуть ли не первый же патч все нормлаьзовал.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В общем, эффективностью пожертвовали ради удобства и простоты. Тем более тут еще бум с ростом ресурсов произошел очень кстати, так что порой и незаметно было , что этот продукт работает в 10 раз медленнее, чем ему положено. Самолет для меня — штука прекрасная, откуда мне знать — его 900 км/час это нормально или нет ? Может, нормально 3000 км/час ? Ничего я в самолетах и аэродинамике не понимаю (допустим) . Все равно, и 900 лучше, чем поездом!
Вот это на самом деле очень важный факт, который ты трактуешь очень странно.
Пользователь выбирает программу, которой пользуется, никак не из-за ее "эффективности", а из-за ее "достаточности". И удобства.
Вот ты привел пример про самолеты. А я привеуд пример про машины.
У меня вот — девятка. Говорят, может разогнаться до 150 км/ч, но с это опасно. На 120 км/ч — вполне сносно.
А ведь есть машины, которые легко разгоянются до 250 км/ч и отлично управляемы на такой скорости.
Есть даже (в мелкосерийном производстве) машины для скоростей за 350 км/ч..
Да. Значит, неэффективна моя девятка.
Так вот — если исходить из критерия эффективности — то мне надо срочно менять машину на такую, которая ну хотя бы уж 250км/ч развивает
Вот только вопрос — зачем, если скорость 90 км/ч по городу я считаю супербыстрой, а 50 — очень удачной?
Какой смысл тратить деньги на то, что практически никогда не пригодится? Я не собираюсь гонять машину по закрытому полигону. мне по городу ездить нужно.
Дальше — развитие темы.
Если выбирать между машинами:
1. макс. 60км/ч, очень удобная, безопасная и комфортная
2. макс 190 км/ч, но некомфортно.
То я просто совершенно однозначно выберу первый вариант.
И с программами та же фигня. Пользователь выбирает баланс между ценой и удобством программы, среди вариантов, которые способны решить нужную ему задачу (глупо сравнивать самолет с поездом, если нужно добраться в Автралию). Медленное выполнение — это только лишний минус к "удобству".
Платить же лишние деньги за какую-то там "эффективность", или тем более — жертвовать ради этого комфортностью работы — никто не будет.
З.Ы.
Я вот не знаю какая скорость нормальна для самолета или для поезда. Я выбираю билеты, сравниваю имеющееся у меня время и деньги, цену билета и время в пути — а потом выбираю — самолет А, самолет Б или поезд. И плевать мне на их эффективность. Ты еще про загрязнение окружающей среды вспомни, ха.
Здравствуйте, eugene0, Вы писали:
E>Вот сайт производителя этого ускорителя E>Только что-то пока ничего особенного с поддержкой этого ускорителя не вышло. E>Во многом потому, что навороченная физика для большинства компьютерных игр довольно сомнительное приобретение. E>Многие без нее обходятся и живут отлично.
Наоборот, это сейчас самая горячая тема. Чисто в графике уже практически достигли фотореализма, дальше только трассировка лучей.
А вот реалистичность физических эффектов как раз может быть selling point. Другой вопрос, что nVidia и ATI естественно просто интегрируют поддержку физических вычислений в последнем поколении своих карт (с помощью Havok FX в частности), да и большинство геймеров в общем-то не горят желанием покупать еще одну дорогую карту.
Здравствуйте, eugene0, Вы писали:
E>Еще, кстати, неслабый удар по производительности вся эта физика.
Вот именно потому целесообразно переносить обсчёт физики на дополнительный процессор.
E>Между тем, есть отличные игры, которые без нее неплохо обходятся. Посмотрите, например, на Call of Duty.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
КЛ>>не говори о том, чего не знаешь. Это просто смешно. Очень очень смешно. К сожалению я не могу раскрывать имена заказчиков. Всем бы таких, да далеко не все могут получить.
VD>Правильно! Никому их имена не рассказвай, а то они узнают кто им код пишут и офигет сразу.
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, Константин Л., Вы писали:
КЛ>>К сожалению я не могу раскрывать имена заказчиков. Всем бы таких, да далеко не все могут получить.
AF>Я догадываюсь! Это наверно называется "откат-софт"?
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, Константин Л., Вы писали:
КЛ>>чего стоит мой — я знаю.
AF>Если у всех в вашей команде такой же опыт как у вашего веб-программиста, то дальше можешь не рассказывать. (подсказываю — люди пользуются многими другими браузерами, кроме IE6. И показывать им "ваш браузер не поддерживается" — вопиющий непрофессионализм)
хм...Ты business-analyst'ом работаешь? Если нет, то тогда лучше бы молчал.
Здравствуйте, eao197, Вы писали:
IT>>Шаблоны и исключения появились намного позже, уже в 90-х.
E>впервые появилась в компиляторах фирм DEC и IBM в начале 1992.
Я же говорю в 90-х.
E>А Cfront, в котором шаблоны появились впервые, был как раз препроцессором.
Cfront вообще кто-нибудь использовал в коммерческих разработках?
E>>> Далее работали штатные C-компиляторы и линкеры конкретной целевой платформы. Первый "родной" компилятор C++, Zortech C++, был написан в конце восьмидесятых для MS-DOS и не поддерживал самых продвинутых возможностей языка.
IT>>Это каких?
E>Как раз шаблонов и исключений Я сталкивался с Zortech C++ годах в 92/93-м -- там этого не было.
Естественно. Этих фич в C++ тогда ещё не было.
IT>>А мозг на что человеку даден? Нужно было подумать им немного.
E>Я вот не могу себе представить другого способа для этого, кроме компиляции не в объектный код, а в код какой-нибудь виртуальной машины. С последующей трансляций в конкретный нативный код.
Можно и так. Turbo Pascal, например, великолепно справлялся с этой задачей в тоже самое время. Ещё тогда же было семейство компиляторов, не помню название, для которых эта задача решалась не для одного, а для множества языков. Так что решить эту задачу было можно, было бы желание.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Шахтер, Вы писали:
VD>>Не допускаешь, что то что ты считаешь нормальным в сравнении с другим языком может оказаться ужасно сложно и медленно?
Ш>Нет, я допускаю, что ты пытаешься подменить предмет обсуждения.
Ухот от ответа можно расцнить как "да, допускаю"?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Переносимость на уровне исходников, это и есть основной приоритет комитета.
К сожалению они добились полностью протевоположенного результата.
DC>Влад в чем заключается мой самообман? В том, что ОС и Драйверы на управляемых языках экспериментальные? Или в том что на данный момент подавляющее большинство ОС и драйверов написано на С++ и/или С?
Самообман то что все перечисленное тобой удобнее писать на С++. Порой вынуждены писать на С/С++ — да. Но никак не удобнее. А вынуждеды по банальной причине — сама ОС написана на С и все интерфейсы у нее тоже в С-формате. Вот и получается, что иногда тебе "удобнее" писать на С++ только лишь потому, что иначе ты не можешь. Хотя на саомо деле можешь, но многие даже в свою голову это уложить не могут.
DC>Т.е С++ говно полюбому? Да Влад это как мантра.
С++ марально устарел еще 5, а то и больше лет назад. Это здравый логический вывод. На мантру скорее похоже бездумное повторение слов роде твоих.
DC>А если компания его использует уже 10-15 лет? Зачем при налаженном процессе переходить куда-то?
Затем, что конкуретны не стоят на месте. И то что сходило с рук 10 лет может не сойти сегодни и завтра.
Первые 3D-игры были написаны на С без скриптов и разных вольностей. В них и 3D-то как такового не было. Второе покоеление уже писалось с использованием скриптов и С++. Следующие должны писаться уже без С++, да и без скриптов. Технологии резко двинулись вперед и мы имеем все что имели и в скриптах, и в С++ (причем без их проблем) в одном флаконе.
DC>Нет, просто на С++ тонны кода,
Серьезно? Ой не верится, что весь этот код будет использоватья в новых проектах. К тому же технологии на сегодня позволяют полжить код в библиотеки и использовать их в другом окружении.
DC> возможности его не сильно хуже существующих управляемых языков.
Вот это уже загиб еще тот. Они не то что бы хуже. По сравнению с лучшеми представителями они катастрофически хуже.
Собственно повторять не охота. Скачай все же презентацию. Погляди ее. С чем ты там собственно не согласен?
DC> Понимаешь чтобы вытеснить С++ нужно предложить что-то намного лучшее. Для Java и .Net снижают стоимость разработки, и порог вхождения низкий, специалистов проще найти. Но только для некоторых областей!!! Где собственно С++ наиболее плох для применения.
Уверяю тебя просто эти области еще не расскачались. Плюс не только Java и .Net существуют в мире. Есть ОКамл, например. Там где Java и .Net могут оказаться не применимы он может дать очень неплохой эффект. У него только одна схожая с С++ проблема — он не поддерживает компонентности. Но он имет существенные приемущества перед С++, так как он типобезопасный, управляет памятью автоматичкски и значительно более выразительный (обладает более мощьными конструкциями).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Да хотя бы то, что возможностей у языка не меньше, а библиотек просто море + это проверенный инструмент.
Оба пункта откровенная лож. Особенно по возможности. Ведь мы не сравниваем возможности с точки зрения машины Тьюринга? Ведь с этой точки зрения все языки (от VB, до ассемблера) равны. А вот проблем у С++ хватает. И варазительность у него явно отстает.
DC>А теперь все таки ответьте на мой вопрос. Что кардинально изменит Немерле или ОКамл. Не просто уменьшат многословность, а именно дадут?
Просто позволят решать более сложные задачи, или решать те же задачи меньшими силами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>А кроме уменьшения многословности ничего дать-то и нельзя. См. Тезис Чёрча. Впрочем, с учетом константности плотности ошибок ничего, кроме краткости, и не требуется.
Кстати, число ошибок не пропорционально объмему кода. Язык очень сильно влияет на их количество. С++ как будто специально спроектирован так, чтобы программист мог допускать трудноуловимые ошибки. ОКамл же и Немерле (за последний зуб даю) проектировались так, чтобы программист совершал как можно меньше ошибок. Так что одинаковый объем код написанный хорошими программистами на Немерле и на С++ не только будут различаться по объему реализованных возможностей (или их сложности), но и будут содержать разное количество ошибок. Что само по себе очень приятно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Все бежим изучать J?
J дает не ту краткость. Это уже краткость в ущерб выразительности. Такая краткость называется сжатием. Это все равно как обсуждать краткость сжатой zip-ом сттатьи. Ну, и что, что она в 10 раз меньше? Прочесть же ее невозможно!
Нам нужна краткость поднимающая выразительность, а не сокращение количества строк/символов любой ценой.
Краткость должна достигаться использованием более мощьных констуркций вроде пасттерн-матчинга и интуитивно понятными умолчаниями. А в J краткость достигается шифроподобными символами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Влад, я мощьности на свой комп ставлю не для микрософта и ее ОС, а для того чтоб прикладное ПО там быстрее бегало.
Ясно. Каждому свое. Я же использую более быстрое железо и более новую ОС чтобы повысить комфорт своей работы, улучшить свое настроение и получить больше фукнциональности. Вот скажем, меня устраивает функционал моего сотового (и темболее домашнего) телефона, и я даже не думаю о том, чтобы купить новый телефон, чтобы на нем что-то там быстрее работало.
DC>[оффтопик] DC>Меня если честно удручает такое положение, я всерьез задумался над переходом на KUbuntu. Я понимаю что мне дал XP — большую стабильность, у меня он стоит уже 4 года, при этом синих экранов вообще не вспомню, подвисаний не больше 3-5 в год, учитывая то, что ставил я много всяких программ. Что мне даст виста? 3D интерфейс который мне не нужен? Какие принципиальные удобства я получу? Исправление собственных багов ценой моих денег и ресурсов моего компа? DC>[/оффтопик]
Ты? Видимо некаких. Я же их уже получил. Незнаю насколько Виста стоит своих денег, но ОС получилась очень удобной. Это первая версия Эксплорера (не IE, а простого) которой я могу пользоваться не протирая монитор от слюней.
Кстати, а зачем ты используешь ХРюшу? Ведь до этого была В2к. Тоже вполне себе ничего ОС. А до этого была просто NT. И она была очень ничего... по тем временам.
DC>. А по сложности задачи? Движок в том или ином виде содержит в себе рендерер. Он правда заточен на другое.
Больше такую глупость никому не говори. Начиная с третьего Квэйка игры рендереры уже практически не содержат. Рендеринг переместился в видеокарту. Причем игры последнего поколения нагружают видиокарту значительно сильнее чем ЦП. По оценкам упоминавшейся тут презентахи соотношение вычислительных затрат таково:
Именно по этому в играх могут использоваться скрипты и именно по этому глупо включать рендереры в состав игр. Хотя несомненно, что рендерер может предоставить куда более высокое качество картинки. Вот только современные процессор еще не достаточно мощьны, чтобы обеспечить приемлемую скорость. И язык или платформа тут ничего не определяют.
DC>Сколько в комитете людей от компаний занимающих производством движков?
Довольно много. Там, кстатити, и МС представлен. Только толку — 0. И стандарта тоже нет. Его уже года 4 отодвигают, и отодвигают. Уже не толко Java с C# появилась, но и следующее поколение проклевывается.
DC>Ты сказал, что стандарт ничего не изменит. Т.е. этот стандарт бред, несуразица
Я сказал, что с точки зрения этой презентации (а стло быть всей разработки игр класса Анрыла) новый стандарт практически ничего не даст. Причем то что помогло бы разработчиком игр было бы одновременно полезным и для большинства других пользователей языка. Но это не путь С++, по всей видимости.
DC>Достаточно хорош — это означает, что любую задачу можно решить используя высокоуровневые конструкции и современные приемы проектирования, при этом добиться максимальной эффективности.
Любую задачу потенциально можно решить на ассемблере или скажем на С. Но это:
1. Не разумно в большинстве случаев.
2. Требует больеш ресурсов и усилий чем может реально быть в распоряжении компании.
DC>Здорово . Только вот переход будет долгим не столько из-за дальновидности или еще чего-то, новый инструмент должен себя зарекомендовать, мало того чтобы вытеснить, он должен дать что-то что кардинально улучшит процесс разработки.
Ага. Но тут есть одна радостная вещь. Те кто окажется прозорливее и свалят вовремя получат ощутимое конкурентное приемущество.
DC>Возможно, время покажет.
Несомненно. Вот только время такая штука... мы оцениваем его только тогда когда оно уже проходит. И обычно если не предпринимать определенных усилий, время конечно все рашает само, но мы оказывамся уже не удел.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Сегодняшнее железо бывает разным, и скажем, на ноутбук, где проблема времени жизни от аккумулятора является одной из важнейших не имеет смысла ставит операционную систему которая будет впустую потреблять много энергии.
Эта мысль замечательна сама по себе, но к сожалению не имеет отношения к реальности. Так как каждая новая ОС как минимум не хуже ведет себя в этом отношении чем предыдущая. Та же Виста позвояет временно отключать Аэро и переходить в весьма экономный режим.
VD>> И это правильно, так как если у меня в машине 3D-акселератор с поддержкой DX 9.0, двух-ядерный процессор и 1-2 гига памяти, то глупо не задействовать это богатство для улучшения комфорта и удобства.
АХ>Глупо не иметь возможности задействовать это богатство. Но так же бессмысленно требовать DX 9.0 видеокарту, двух-ядерный процессор и 1-2 гига памяти на офисном компе у секретарши на котором в основном читают почту и серфят Инет.
Дык никто и не требует. Альтернатив море. Секретарша может использовать ХРюшу, или выключить Аэро если ее машина не его не тянет.
Прогресс же не для секритарш на которых экономит начальство.
У меня самого две машины. Ноут и десктоп. Ноут по слабей, да и ОС на нем уже стоит. Менять я ее если и будут, то сильно позже. А десктоп вот новый. Со всем необходимым для Висты. Что же мне теперь ради солидарности с неграми использовать менее удобную ОС на которую нужно ставить кучу дров чтобы только она заработала на моем новом железе? Вовсе нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eugene0, Вы писали:
E>А вот, ни в коем случае не в плане аргументации, просто как заметка. E>Ради интереса посмотрел объем исходиков в проекте, над которым сейчас работаю (3D-шутер для PC, находится на завершающей стадии разработки). E>Примерно 5 мегов исходников на C++, не считая сторонних библиотек, и 1 мег скриптов. E>Реальность, данная мне в ощущениях
Данные похожие на данные из приводимой мной презентации, но они мало что говорят об оправданности такого решения.
Из той же презентации видно, что на всю симуляцию игры уходит около 10% процессорного времени:
Из той же презентации ясно, что объе этого кода несколько больше чем объем вычислительного кода (который по всей видимости и принято считать кодом тех самых "движков"). Там указывалось, что объем вычислительного кода и объм кода симуляции написанный на С++ приблизительно одинаков 250 000 строк, но код симуляции к тому же еще содержит скрипты на языке похожем на Яву.
Учитывая, что, например, дотнет если и дает проигрыш в производительности, то он все равно измеряется в процентакх, и то, что процессорные затраты на него не велики, то не кажется ли тебе не разумным писать этот код на С++? Если вместо скрипа использовать безопасный, удобный, но быстрый язык — то вы могли бы значительно упростить себе работу при этом практически ничего не потеряв в производительности.
В итоге вы могли бы больше времени потратить на остальные части игры, или просто быстрее выпустить игру сделав ее при этом более надежной.
Так чем же тогда собственно определяется использование С++ хотя бы в области симуляции?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eugene0, Вы писали:
J>>Я всего ее кода не видел, только маленький кусок, но что я увидел там: она была написала на С++, и более того, стратегии AI для игры за разные страны (там у разных стран разные строения, оружие, стоимость ресурсов и прочее, поэтому по-разному надо действовать) были тоже написаны на С++ и упрятаны в DLL-ки с названиями стран (т.е. если ты хотел играть против, скажем, Австрии, то просто подгружалась соответствующая DLL-ка и начинала против тебя играть). На моей тогдашней слабенькой машинке все летало.
E>Предполагаю, что такой подход использовали именно из-за того, что там такое огромное кол-во юнитов на поле одновременно. Возможно, скриптовый движок не потянул такое кол-во выполняемых одновременно скриптов. E>IMHO если юнитов поменьше (у нас, например, обычно не больше 20), то лучше все-таки писать скрипты. Тогда можно будет переложить работу с программистов на дизайнеров миссий, что во многих отношениях правильно.
Ребяты (с). Создать 64К простых юнитов не проблема. Представляй каждого из них простой структурой лежащей в массиве и нет проблем.
Скрипты этого скорее всего не позволят, но ведь кроме скриптов и С++ есть еще кое какие языки.
Мне вот интересно что даст скрипт по сравнению с тем же Немерле?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Дык и работает, только вот фортрановский модуль на AIX-е нигде кроме AIX-а работать не будет. Да и работать будет, потому что JNI на AIX-е реализуется через нативные AIX-овские коды. В таких условиях и к C++ модули C/Fortran спокойно линкуются.
Здравствуйте, Константин Л., Вы писали:
КЛ>хм...Ты business-analyst'ом работаешь? Если нет, то тогда лучше бы молчал.
А при чем здесь аналисты? Всё очень просто. Если так экономят на разработчиках сайта, который есть "лицо фирмы" — значит, на всё остальном экономят еще жестче.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А это один из критериев качества. Быстрее, меньше памяти требуется и т.д.
Качество — это когда программа делает свою работу правильно, не падает и не рушится. А скорость — это отдельный параметр, и к качеству никакого отношения не имеет.
Bulat,
BZ>преимущества Хаскела — очень строгая типизация, отлавливающая большинство ошибок с типами, и лёгкость конструирования алгоримтов из составных частей. я не представляю себе потребности игр,
Тим Свини в своей презентации утверждает, что очень хочется статического контроля выхода за пределы массивов, статического контроля за null-значениями, статического контроля за переполнением, хорошей поддержки concurrency, и подобные мелочей.
BZ>вот напоследок ещё один небольшой алгоритм. суть его в том, что есть а-ля RAR список номеров сбойных секторов в архиве и его надо разделить на две части — секторы, чей номер по модулю rec_sectors уникален (их можно восстановить), от тех, которые накладываются друг на друга:
Здравствуйте, dr.Chaos, Вы писали: DC>Ну уж нет, Си явно выражал концепцию структурного программирования, т.е. вводил новые абстракции что ли.
С действительно компактнее ассемблера, чем и рулит. С++ компактнее С. Новые абстракции не нужны сами по себе — они оправданы только тем, что сокращают запись. Тензорное исчисление само по себе ничего нового не дает по сравнению с обычной алгеброй. Просто более компактная запись длинных уравнений.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали: VD>Кстати, число ошибок не пропорционально объмему кода. Язык очень сильно влияет на их количество. С++ как будто специально спроектирован так, чтобы программист мог допускать трудноуловимые ошибки.
В некоторой степени согласен. Но в первую очередь ошибки С++ лежат там же, где и многословность. Например, встроенные указатели максимально компактны при определении, а любые мимикрирующие под них обертки — длиннее. Поэтому всегда есть искушение обойтись char* вместо std::string, и нарваться там ровно на все грабли с выходом за границы и несвоевременным уничтожением. VD>ОКамл же и Немерле (за последний зуб даю) проектировались так, чтобы программист совершал как можно меньше ошибок. Так что одинаковый объем код написанный хорошими программистами на Немерле и на С++ не только будут различаться по объему реализованных возможностей (или их сложности), но и будут содержать разное количество ошибок. Что само по себе очень приятно.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
J>>>Я всего ее кода не видел, только маленький кусок, но что я увидел там: она была написала на С++, и более того, стратегии AI для игры за разные страны (там у разных стран разные строения, оружие, стоимость ресурсов и прочее, поэтому по-разному надо действовать) были тоже написаны на С++ и упрятаны в DLL-ки с названиями стран (т.е. если ты хотел играть против, скажем, Австрии, то просто подгружалась соответствующая DLL-ка и начинала против тебя играть). На моей тогдашней слабенькой машинке все летало.
E>>Предполагаю, что такой подход использовали именно из-за того, что там такое огромное кол-во юнитов на поле одновременно. Возможно, скриптовый движок не потянул такое кол-во выполняемых одновременно скриптов. E>>IMHO если юнитов поменьше (у нас, например, обычно не больше 20), то лучше все-таки писать скрипты. Тогда можно будет переложить работу с программистов на дизайнеров миссий, что во многих отношениях правильно.
VD>Ребяты (с). Создать 64К простых юнитов не проблема. Представляй каждого из них простой структурой лежащей в массиве и нет проблем.
Создать столько юнитов, конечно, не проблема. Но представь себе, что каждый из этих юнитов есть интерпретатор или виртуальная машинка, выполняющая скрипт и все это одновременно.
VD>Скрипты этого скорее всего не позволят, но ведь кроме скриптов и С++ есть еще кое какие языки.
VD>Мне вот интересно что даст скрипт по сравнению с тем же Немерле?
В играх скрипт по сравнению с С++ и другими языками дает обычно два приемущества:
1) в скриптах как правило не пишется архитектурно сложного кода, поэтому их пишут не программисты, а дизайнеры миссий/уровней/карт, которые в силу специфики своей работы скриптовыми языками владеют, а С++ и Немерле — нет.
2) когда логика поведения юнитов написана на скриптах, дизайнер может менять ее без перекомпиляции кода. На самом деле ему вообще не нужны исходники игры, хватит исполняемых файлов.
Здравствуйте, eugene0, Вы писали:
E>Мы тут пытаемся использовать тот самый PhysX
Привет, коллега!
E>Дело в том, что физический движок весьма сложен в настройке, да и багов в нем предостаточно.
Не столько сложен, сколько сыроват. Работал с Havok 2 — тот гораздо стабильнее. Впрочем и в нем тогда с ragdoll была проблема, которую даже с их саппортом решить не удалось.
E>Между тем, есть отличные игры, которые без нее неплохо обходятся. Посмотрите, например, на Call of Duty.
Главное в игре — геймплей. Все остальное — призвано помогать улучшать этот геймплей. ИМХО...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, konsoletyper, Вы писали:
E>>Между тем, есть отличные игры, которые без нее неплохо обходятся. Посмотрите, например, на Call of Duty.
K>Контрпример — Silent Storm.
Еще есть Half-Life 2. Без динамики твердых тел в ней все было бы намного скучнее
Здравствуйте, IT, Вы писали:
IT>>>Шаблоны и исключения появились намного позже, уже в 90-х.
E>>впервые появилась в компиляторах фирм DEC и IBM в начале 1992.
IT>Я же говорю в 90-х.
И?
Вторая версия C++ появилась как раз во время работы над ARM, а это период с 1988 по 1990-й. И как раз в это время шаблоны и исключения появились в языке. Реализации вышли позже, но для C++ это обычное дело.
Так что я не вижу противоречий по сравнению с тем, что я говорил здесь
E>>А Cfront, в котором шаблоны появились впервые, был как раз препроцессором.
IT>Cfront вообще кто-нибудь использовал в коммерческих разработках?
По словам Страуструпа, Cfront активно использовался в разработках самой AT&T.
IT>>>А мозг на что человеку даден? Нужно было подумать им немного.
E>>Я вот не могу себе представить другого способа для этого, кроме компиляции не в объектный код, а в код какой-нибудь виртуальной машины. С последующей трансляций в конкретный нативный код.
IT>Можно и так. Turbo Pascal, например, великолепно справлялся с этой задачей в тоже самое время. Ещё тогда же было семейство компиляторов, не помню название, для которых эта задача решалась не для одного, а для множества языков. Так что решить эту задачу было можно, было бы желание.
Ну не было у меня возможности переносить объектные файлы Turbo Pascal 3.0 с Robotron 1715 и CP/M на Turbo Pascal 5.0 на IBM XT и MS-DOS. И не знаю я про существование Turbo Pascal для SPARC-овых или MIPS-овых архитектур. Например, можно ли было tpu-файлы из Turbo Pascal на Маках использовать?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
IT>>>>Шаблоны и исключения появились намного позже, уже в 90-х.
C++ 1.x — одиночное наследование, реализован в Zortech C++ 1.0
C++ 2.0 — множественное наследование, реализован в Zortech C++ 2.0 и Turbo C++ 1.0 (май 90-го)
С++ 2.1 — templates & exceptions
хотя я могу ошибаться и возможно exceptions появились только в 3.0. Во всяком случае, Borland C++ 92-го года реализовывал только шаблоны
E>>>А Cfront, в котором шаблоны появились впервые, был как раз препроцессором.
IT>>Cfront вообще кто-нибудь использовал в коммерческих разработках?
E>По словам Страуструпа, Cfront активно использовался в разработках самой AT&T.
По моему в том же дизайне и эволюции сказано, что CFront был основой для многих коммерческих компиляторов.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Да хотя бы то, что возможностей у языка не меньше, а библиотек просто море + это проверенный инструмент.
VD>Оба пункта откровенная лож. Особенно по возможности. Ведь мы не сравниваем возможности с точки зрения машины Тьюринга? Ведь с этой точки зрения все языки (от VB, до ассемблера) равны. А вот проблем у С++ хватает. И варазительность у него явно отстает.
Каких возможностей не хватает в С++ : сопоставления с образцом? — В движках всегда switch'a хватало; Замыканий? — да могу я их сделать функторами; как собственно и ФВП ; да это не будет так красиво, и кратко как в ОКамле или Немерле.
Только объясни мне где в алгоритмах в движке их применять. Я, если честно, не вижу сильного выигрыша от их применения.
Кстати, пункта три. Какие именно ты ложью назвал? .
DC>>А теперь все таки ответьте на мой вопрос. Что кардинально изменит Немерле или ОКамл. Не просто уменьшат многословность, а именно дадут?
VD>Просто позволят решать более сложные задачи, или решать те же задачи меньшими силами.
Вот блин опять абстракция, я про движок графический спрашиваю. То что в физическом движке ФП будет возможно лучше использовать, я соглашусь, но ты мне объясни где я выиграю в 3D движке???
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, eugene0, Вы писали: E>Создать столько юнитов, конечно, не проблема. Но представь себе, что каждый из этих юнитов есть интерпретатор или виртуальная машинка, выполняющая скрипт и все это одновременно.
Это, как бы это сказать, наивный подход. Можно моделировать юниты процессами ОС, получая чудовищные накладные расходы, и кричать: вот, вот тормоза! ату их! скрипты — сосуд!
Можно понять, что 64к однотипных юнитов выполняют ровно один и тот же скрипт, а состояние у каждого весьма примитивное, и применить некоторые хитрые оптимизации. Я в свое время изобретал такую штуку для оптимизации виртуальных вызовов на Delphi. Т.е. вся одновременность там очень ограниченная, контекст очень дешевый, и пробежаться в цикле по 64к структурок стоит практически нуль.
А можно замоделировать их на каком-нибудь эрланге, и он сделает все то же, что в предыдущем пункте, только гораздо дешевле в плане ручного труда.
E>В играх скрипт по сравнению с С++ и другими языками дает обычно два приемущества: E>1) в скриптах как правило не пишется архитектурно сложного кода, поэтому их пишут не программисты, а дизайнеры миссий/уровней/карт, которые в силу специфики своей работы скриптовыми языками владеют, а С++ и Немерле — нет.
Это очень странная специфика, если честно. Про с++ я еще понимаю — это очень требовательный язык. Хотя я и на его основе бы смог, скорее всего, наколбасить псевдоязык для дизайнеров с предельно упрощенным синтаксисом. А уж Nemerle с его супергибкими способностями и вовсе можно было бы замаскировать практически под Лого (который, скорее всего, и нужен для игровых скриптов). E>2) когда логика поведения юнитов написана на скриптах, дизайнер может менять ее без перекомпиляции кода. На самом деле ему вообще не нужны исходники игры, хватит исполняемых файлов.
В 21 веке понятие "перекомпиляция" существенным образом изменило свой смысл. Насколько я знаю, современные 3d игрушки работают с предкомпилированными описаниями уровней, которые готовятся довольно долго (чтобы сэкономить время на загрузке карты). Поэтому можно считать, что логика просто проходит через какой-то конвеер, на одном конце которого — исходник, а на другом — нативный код. К слову, в управляемых языках даже полный конвеер очень быстр, благодаря чему работают всякие .*sp с compile-on-demand. Поэтому особенного выигрыша от интерпретации получить не удастся.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали: VD>Так чем же тогда собственно определяется использование С++ хотя бы в области симуляции?
Да тем, Влад, и определяется. Инерцией. У меня лично переход на ASP.NET для разработки веб приложений занял примерно два года, и только теперь я понимаю, что такое хорошее веб приложение и как его правильно писать. Причем наше приложение еще не удовлетворяет этим моим представлениям — потому, что значительная его часть писалась до того, как я всё понял. И еще не факт, что то, что я понял суть истина.
Так и гейм девелопмент: менеджеру продукта приходится на старте выбирать из шага в неизвестность, которая теоретически может дать какой-то выигрышь, и движения в уже известную сторону. Разработчик не знает заранее, сколько времени у него займет изучение Nemerle; архитектор не знает, сколько времени у него уйдет на изобретение DSL, подходящего для конкретной области, менеджер не знает, какие грабли встретятся при поиске и использовании сторонних разработок. А продюсер требует показать бизнес план.
Вот народ и ездит на чем умеет. Они дожидаются, пока:
— кто-то рискнет попробовать написать реальную игру на Nemerle и разорится (из-за недооценки трудностей, или из-за того, что архитектор только через полгода поймет, что DSL должен был быть устроен совсем не так, а уже поздно)
— кто-то учтет предыдущий негативный опыт и доведет таки игру до конца, показав, что Nemerle не хуже плюсов
— кто-то учтет позитивный опыт и сварганит фреймворк, который таки будет мегаудобным и станет стандартом де-факто
— кто-то на основе этого фреймворка напишет и издаст книгу Painless Game Develompent, которая станет бестселлером типа Абрашевского труда
— к моменту выхода книги будет доступно два-три конкурирующих фреймворка, которые будут непрерывно мериться разными органами, а ведущие блоггеры будут это комментировать.
Вот тогда-то инерционный менеджмент и решит, что "ну, вот и нам пора".
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, BulatZiganshin, Вы писали:
IT>>>>>Шаблоны и исключения появились намного позже, уже в 90-х.
BZ>C++ 1.x — одиночное наследование, реализован в Zortech C++ 1.0
Если я правильно помню и понимаю "Дизайн и эволюцию языка C++", то возможности C++ 2.0 реализовывались в период с 1987 по 1990 год в компиляторе Cfront. Страуструп вроде как сетовал на то, что с выпуском версии 2.0 они очень затянули как раз из-за того, что у них были сложности с реализацией шаблонов -- первая реализация, отсюда и все грабли.
Поэтому, когда в 1988-м появился первый Zortech с поддержкой C++ 1.x, то в AT&T возможности C++ 2.0 уже были частично доступны в Cfront. А вот был ли этот Cfront доступен еще кому-то вне AT&T -- не знаю.
BZ>C++ 2.0 — множественное наследование, реализован в Zortech C++ 2.0 и Turbo C++ 1.0 (май 90-го) BZ>С++ 2.1 — templates & exceptions
BZ>хотя я могу ошибаться и возможно exceptions появились только в 3.0. Во всяком случае, Borland C++ 92-го года реализовывал только шаблоны
Как утверждает Wikipedia, Borland выпускал две линейки C++ компиляторов: Turbo C++ и Borland C++.
Я видел и пользовался только Turbo C++ 1.0, затем Borland C++ 2.0, 3.1, 4.0 и 4.5. Turbo C++ 3.0 прошел мимо меня
Я не уверен на счет шаблонов в Borland C++ 3.1. В Borland C++ 2.0 их точно не было.
Я начал экспериментировать с шаблонами и исключениями только после того, как в 95-м мне в руки попал Borland C++ 4.0 и 4.5. Причем, если не ошибаюсь, шаблоны появились именно в Borland C++ 4.0, а в Borland C++ 4.5 -- исключения.
К тому же не знаю, как в крупных городах, но к нам в провинцию в то время инструменты попадали с серьезным запозданием
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Переносимость на уровне исходников, это и есть основной приоритет комитета.
VD>К сожалению они добились полностью протевоположенного результата.
Какого? Переносимости на уровне исходников нет? . Ты открыл мне глаза. Только как я компилюсь каждый деть с одним кодом под Win/AIX, может я что-то неправильно делаю??
DC>>Влад в чем заключается мой самообман? В том, что ОС и Драйверы на управляемых языках экспериментальные? Или в том что на данный момент подавляющее большинство ОС и драйверов написано на С++ и/или С?
VD>Самообман то что все перечисленное тобой удобнее писать на С++. Порой вынуждены писать на С/С++ — да. Но никак не удобнее. А вынуждеды по банальной причине — сама ОС написана на С и все интерфейсы у нее тоже в С-формате. Вот и получается, что иногда тебе "удобнее" писать на С++ только лишь потому, что иначе ты не можешь. Хотя на саомо деле можешь, но многие даже в свою голову это уложить не могут.
Влад удобнее хотя бы потому, как это проверенный временем инструмент. Те что по-новее пока в стадии, если не разработки, то активного тестирования — не дальше.
DC>>Т.е С++ говно полюбому? Да Влад это как мантра.
VD>С++ марально устарел еще 5, а то и больше лет назад. Это здравый логический вывод.
В чем его моральная старость? Кто кроме С++ дает такие возможности с обобщенным программированием при строгой типизации? Java, .Net? VD>На мантру скорее похоже бездумное повторение слов роде твоих.
Каких именно слов? То, что это достаточно хороший инструме DC>>А если компания его использует уже 10-15 лет? Зачем при налаженном процессе переходить куда-то?
VD>Затем, что конкуретны не стоят на месте. И то что сходило с рук 10 лет может не сойти сегодни и завтра.
Влад кто из производителей движков/ОС/драйверов переходит на Немерле/ОКамл/...
VD>Первые 3D-игры были написаны на С без скриптов и разных вольностей. В них и 3D-то как такового не было.
Тогда и акселераторов то не было. VD>Второе покоеление уже писалось с использованием скриптов и С++.
Использование скриптов ИМХО еще позже появилось. VD>Следующие должны писаться уже без С++, да и без скриптов. Технологии резко двинулись вперед и мы имеем все что имели и в скриптах, и в С++ (причем без их проблем) в одном флаконе.
Кому должны и где имеем? Где 3Д библиотеки для Немерле/ОКамл/... которые удовлетворяют разработчиков движков?
DC>>Нет, просто на С++ тонны кода,
VD>Серьезно? Ой не верится, что весь этот код будет использоватья в новых проектах. К тому же технологии на сегодня позволяют полжить код в библиотеки и использовать их в другом окружении.
Да никто не запрещают, многие так и делают . Кстати весьма правильно делают. Кесарю — кесарево.
DC>> возможности его не сильно хуже существующих управляемых языков.
VD>Вот это уже загиб еще тот. Они не то что бы хуже. По сравнению с лучшеми представителями они катастрофически хуже.
Какие поименно? — причем в разрезе применения для ОС/драйверов/графических движков.
VD>Собственно повторять не охота. Скачай все же презентацию. Погляди ее. С чем ты там собственно не согласен?
DC>> Понимаешь чтобы вытеснить С++ нужно предложить что-то намного лучшее. Для Java и .Net снижают стоимость разработки, и порог вхождения низкий, специалистов проще найти. Но только для некоторых областей!!! Где собственно С++ наиболее плох для применения.
VD>Уверяю тебя просто эти области еще не расскачались. Плюс не только Java и .Net существуют в мире. Есть ОКамл, например. Там где Java и .Net могут оказаться не применимы он может дать очень неплохой эффект. У него только одна схожая с С++ проблема — он не поддерживает компонентности. Но он имет существенные приемущества перед С++, так как он типобезопасный, управляет памятью автоматичкски и значительно более выразительный (обладает более мощьными конструкциями).
Я с этим и не спорил никогда.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, AndreiF, Вы писали:
AF>Качество — это когда программа делает свою работу правильно, не падает и не рушится. А скорость — это отдельный параметр, и к качеству никакого отношения не имеет.
А самолет, который я описал, движется ? Да. Летает со скоростью 100 км/час. И даже, может, и не падает. Жрет горючее как 100 Боингов, но летает
Ну и счастливого полета на этом качественном самолете. В соседнюю деревню, За рогами и копытами.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Влад, я мощьности на свой комп ставлю не для микрософта и ее ОС, а для того чтоб прикладное ПО там быстрее бегало.
VD>Ясно. Каждому свое. Я же использую более быстрое железо и более новую ОС чтобы повысить комфорт своей работы, улучшить свое настроение и получить больше фукнциональности. Вот скажем, меня устраивает функционал моего сотового (и темболее домашнего) телефона, и я даже не думаю о том, чтобы купить новый телефон, чтобы на нем что-то там быстрее работало.
Влад я не хочу менять комп, ради того чтобы Виста там смогла!! работать. Предоставляемые удобства весьма сомнительныно выше чем у Линукса
DC>>[оффтопик] DC>>Меня если честно удручает такое положение, я всерьез задумался над переходом на KUbuntu. Я понимаю что мне дал XP — большую стабильность, у меня он стоит уже 4 года, при этом синих экранов вообще не вспомню, подвисаний не больше 3-5 в год, учитывая то, что ставил я много всяких программ. Что мне даст виста? 3D интерфейс который мне не нужен? Какие принципиальные удобства я получу? Исправление собственных багов ценой моих денег и ресурсов моего компа? DC>>[/оффтопик]
VD>Ты? Видимо некаких. Я же их уже получил. Незнаю насколько Виста стоит своих денег, но ОС получилась очень удобной. Это первая версия Эксплорера (не IE, а простого) которой я могу пользоваться не протирая монитор от слюней.
VD>Кстати, а зачем ты используешь ХРюшу? Ведь до этого была В2к. Тоже вполне себе ничего ОС. А до этого была просто NT. И она была очень ничего... по тем временам.
Потому как драйверов под них не найдешь, да и на 64 разрядный камень нет сборки. Кроме того под NT нормально игры не запускаются, он не для этого разрабатывался.
DC>>. А по сложности задачи? Движок в том или ином виде содержит в себе рендерер. Он правда заточен на другое.
VD>Больше такую глупость никому не говори.
Читай выделенное.для рендеринга просто используется как ты правильно заметил дополнительный специализированный процессор.
DC>>Сколько в комитете людей от компаний занимающих производством движков?
VD>Довольно много. Там, кстатити, и МС представлен. Только толку — 0. И стандарта тоже нет. Его уже года 4 отодвигают, и отодвигают. Уже не толко Java с C# появилась, но и следующее поколение проклевывается.
MC там представлен я не сомневаюсь, только MC не производитель движков.
DC>>Ты сказал, что стандарт ничего не изменит. Т.е. этот стандарт бред, несуразица
VD>Я сказал, что с точки зрения этой презентации (а стло быть всей разработки игр класса Анрыла) новый стандарт практически ничего не даст. Причем то что помогло бы разработчиком игр было бы одновременно полезным и для большинства других пользователей языка. Но это не путь С++, по всей видимости.
Оооо. Сколько оговорок появилось для простой фразы — Ничего не изменит.
DC>>Достаточно хорош — это означает, что любую задачу можно решить используя высокоуровневые конструкции и современные приемы проектирования, при этом добиться максимальной эффективности.
VD>Любую задачу потенциально можно решить на ассемблере или скажем на С. Но это: VD>1. Не разумно в большинстве случаев. VD>2. Требует больеш ресурсов и усилий чем может реально быть в распоряжении компании.
С и Асм не предоставляют столько высокоуровневых абстракций для проектирования. Мало того на С++ действительно неразумно решать многие задачи, т.к. появились специализированные инструменты.
DC>>Здорово . Только вот переход будет долгим не столько из-за дальновидности или еще чего-то, новый инструмент должен себя зарекомендовать, мало того чтобы вытеснить, он должен дать что-то что кардинально улучшит процесс разработки.
VD>Ага. Но тут есть одна радостная вещь. Те кто окажется прозорливее и свалят вовремя получат ощутимое конкурентное приемущество.
Я и не сомневаюсь, только до этого, как ты сам оценил 5-10 лет.
DC>>Возможно, время покажет.
VD>Несомненно. Вот только время такая штука... мы оцениваем его только тогда когда оно уже проходит. И обычно если не предпринимать определенных усилий, время конечно все рашает само, но мы оказывамся уже не удел.
С++-шники не у дел не останутся . Они просто перейдут в другие области.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, CreatorCray, Вы писали:
E>>Мы тут пытаемся использовать тот самый PhysX CC>Привет, коллега!
E>>Дело в том, что физический движок весьма сложен в настройке, да и багов в нем предостаточно. CC>Не столько сложен, сколько сыроват. Работал с Havok 2 — тот гораздо стабильнее. Впрочем и в нем тогда с ragdoll была проблема, которую даже с их саппортом решить не удалось.
Хавок денег стоит, насколько мне известно. Нам их не дадут
E>>Между тем, есть отличные игры, которые без нее неплохо обходятся. Посмотрите, например, на Call of Duty. CC>Главное в игре — геймплей. Все остальное — призвано помогать улучшать этот геймплей. ИМХО...
В принципе я согласен. Но когда гранаты проваливаются сквозь землю, а трупы дергаются эпилептически — это
Классчический Фортран работает ОЧЕНЬ быстро из-за огромных возможностей
по оптимизации (отсутствие aliasing'а, рекурсии, встроенные многомерные
массивы и комплексные числа, простой язык). .NETовый JIT таких
возможностей и близко не имеет.
Здравствуйте, dr.Chaos, Вы писали:
VD>>С++ марально устарел еще 5, а то и больше лет назад. Это здравый логический вывод. DC>В чем его моральная старость? Кто кроме С++ дает такие возможности с обобщенным программированием при строгой типизации? Java, .Net?
Eiffel с 80-х годов. оттуда кстати оно и было в C++ перенесено у меня есть на 25 кил письмо автора этого языка где-то 87-го года, где он критикует C++. можешь считать добавление exceptions/templates работой над ошибками
вообще C++ вырос из "высокоуровневого ассемблера" и на нынешнем уровне его применение имхо оправдано только когда нужна максимальная производительность. а все добавления последних 10-15 лет — это просто эмуляция возможностей более высокоуровневых языков, от умных указателей до лямбд.
я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет
Здравствуйте, Sinclair, Вы писали:
E>>Создать столько юнитов, конечно, не проблема. Но представь себе, что каждый из этих юнитов есть интерпретатор или виртуальная машинка, выполняющая скрипт и все это одновременно. S>Это, как бы это сказать, наивный подход. Можно моделировать юниты процессами ОС, получая чудовищные накладные расходы, и кричать: вот, вот тормоза! ату их! скрипты — сосуд! Я что-то писал про процессы или потоки?
S>Можно понять, что 64к однотипных юнитов выполняют ровно один и тот же скрипт, а состояние у каждого весьма примитивное, и применить некоторые хитрые оптимизации. Я в свое время изобретал такую штуку для оптимизации виртуальных вызовов на Delphi. Т.е. вся одновременность там очень ограниченная, контекст очень дешевый, и пробежаться в цикле по 64к структурок стоит практически нуль. S>А можно замоделировать их на каком-нибудь эрланге, и он сделает все то же, что в предыдущем пункте, только гораздо дешевле в плане ручного труда.
На ум приходят всякие доводы за и против, но на самом деле все это ни к чему. Если ты посмотришь немного выше по ветке, я всего лишь предположил, почему в вышеупомянутых казаках логика поведения юнитов полностью захардкодена, а не написана на скриптах. Таких причин может быть очень много, от более или менее разумных до "тимлид сказал". Я к команде разработчиков той игры отношения не имею, поэтому совершенно не в курсе, почему они так сделали.
E>>В играх скрипт по сравнению с С++ и другими языками дает обычно два приемущества: E>>1) в скриптах как правило не пишется архитектурно сложного кода, поэтому их пишут не программисты, а дизайнеры миссий/уровней/карт, которые в силу специфики своей работы скриптовыми языками владеют, а С++ и Немерле — нет. S>Это очень странная специфика, если честно. Про с++ я еще понимаю — это очень требовательный язык. Хотя я и на его основе бы смог, скорее всего, наколбасить псевдоязык для дизайнеров с предельно упрощенным синтаксисом. S> А уж Nemerle с его супергибкими способностями и вовсе можно было бы замаскировать практически под Лого (который, скорее всего, и нужен для игровых скриптов).
Зачем что-то колбасить? Вот LUA, вот python. Для того, чтобы делать что-то новое, нужно, чтобы это новое было чем-то лучше, чем готовое и многократно использованное и оттестированное старое. Чем вот эти псевдоязыки были бы лучше?
E>>2) когда логика поведения юнитов написана на скриптах, дизайнер может менять ее без перекомпиляции кода. На самом деле ему вообще не нужны исходники игры, хватит исполняемых файлов. S>В 21 веке понятие "перекомпиляция" существенным образом изменило свой смысл. Насколько я знаю, современные 3d игрушки работают с предкомпилированными описаниями уровней, которые готовятся довольно долго (чтобы сэкономить время на загрузке карты). Поэтому можно считать, что логика просто проходит через какой-то конвеер, на одном конце которого — исходник, а на другом — нативный код. К слову, в управляемых языках даже полный конвеер очень быстр, благодаря чему работают всякие .*sp с compile-on-demand. Поэтому особенного выигрыша от интерпретации получить не удастся.
За все современные игрушки не скажу, а у нас дела обстоят следующим образом. Есть некий самодельный инструмент — редактор уровней, главный инструмент дизайнеров. В нем можно рассмотреть игровой мир со всех сторон, подвигать объекты, поменять их свойства. Еще там же можно давать объектам на выполнение различные скрипты, тут же их править, запускать снова.
Дизайнер может действовать так: он строит сцену из готовых объектов, настрайвает их свойства, пишет скрипты. Это обычно происходит в режиме "на паузе". После этого он сохраняет сцену, запускает ее и смотрит, что получилось. Обычно, сначала что-нибудь идет не так, как хотелось. Тогда дизайнер перегружает сцену, подправляет ее немного (передвигает неправильно стоящий объект, правит скрипт и т.д.), сохраняет, смотрит, что получилось. И т.д. и т.п.
При этом никаких длительных перерывов в его работе нет, из редактора он не выходит. Если бы вместо скриптов была захардкоденная логика, ему пришлось бы выходить, править, перекомпилировать как минимум тот модуль, который он поправил.
Вот о чем я пытался сказать выше. Насколько мне известо, разработка уровней организована таким образом не только у нас.
Здравствуйте, BulatZiganshin, Вы писали:
VD>>>С++ марально устарел еще 5, а то и больше лет назад. Это здравый логический вывод. DC>>В чем его моральная старость? Кто кроме С++ дает такие возможности с обобщенным программированием при строгой типизации? Java, .Net?
BZ>Eiffel с 80-х годов. оттуда кстати оно и было в C++ перенесено у меня есть на 25 кил письмо автора этого языка где-то 87-го года, где он критикует C++. можешь считать добавление exceptions/templates работой над ошибками
Eiffel появился в 86-м. Да и его generic-и больше похожи на нынешние generic-и в Java, чем на шаблоны C++. И шаблоны в C++ пришли вовсе не из Eiffel, а из Ada и Clu.
BZ>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет
Я постоянно пишу многопоточные программы на C++ и проблем с синхронизаций практически не возникает. Потому что специально заточенным для этого инструментом пользуюсь. Так что функциональность или императивность языка здесь дело далеко не принципиальное.
И не знаю, как остальные сторонники C++ в данной ветке, но я отнюдь не утверждаю, что после C++ лучше ничего не будет. А призываю к тому, чтобы в C++ камнями перестали кидаться от нечего делать.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, dr.Chaos, Вы писали: DC>>Ну уж нет, Си явно выражал концепцию структурного программирования, т.е. вводил новые абстракции что ли. S>С действительно компактнее ассемблера, чем и рулит. С++ компактнее С. Новые абстракции не нужны сами по себе — они оправданы только тем, что сокращают запись. Тензорное исчисление само по себе ничего нового не дает по сравнению с обычной алгеброй. Просто более компактная запись длинных уравнений.
Не только. Новые абстракции нужны для разбиения на части модели. Это локально снижает сложность.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, BulatZiganshin, Вы писали:
BZ>преимущества Хаскела — очень строгая типизация, отлавливающая большинство ошибок с типами, и лёгкость конструирования алгоримтов из составных частей. я не представляю себе потребности игр, но вот к примеру печать простых чисел:
Жаль у меня нет куска кода для оптимизации сцены при преобразовании во внутренний формат движка . Могли бы провести эксперимент .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, dr.Chaos, Вы писали:
VD>>>С++ марально устарел еще 5, а то и больше лет назад. Это здравый логический вывод. DC>>В чем его моральная старость? Кто кроме С++ дает такие возможности с обобщенным программированием при строгой типизации? Java, .Net?
BZ>Eiffel с 80-х годов. оттуда кстати оно и было в C++ перенесено у меня есть на 25 кил письмо автора этого языка где-то 87-го года, где он критикует C++. можешь считать добавление exceptions/templates работой над ошибками
BZ>вообще C++ вырос из "высокоуровневого ассемблера" и на нынешнем уровне его применение имхо оправдано только когда нужна максимальная производительность. а все добавления последних 10-15 лет — это просто эмуляция возможностей более высокоуровневых языков, от умных указателей до лямбд.
BZ>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет
Вот, блин ты мне приведи то место где Я это сказал.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, eugene0, Вы писали: E> Я что-то писал про процессы или потоки?
Ты — нет. Ты писал про виртуальные машины. Вот, к примеру, каждая Java VM выполняется в отдельном процессе.
E>На ум приходят всякие доводы за и против, но на самом деле все это ни к чему. Если ты посмотришь немного выше по ветке, я всего лишь предположил, почему в вышеупомянутых казаках логика поведения юнитов полностью захардкодена, а не написана на скриптах.
Я понимаю, и я хардкод упомянул как один из вариантов. Но он не противопоставляется ни VM, ни интерпретатору, который бегает по кругу. E>Зачем что-то колбасить? Вот LUA, вот python. Для того, чтобы делать что-то новое, нужно, чтобы это новое было чем-то лучше, чем готовое и многократно использованное и оттестированное старое. Чем вот эти псевдоязыки были бы лучше?
Ну, чисто теоретически, они бы еще сильнее контролировали дизайнера. Я, честно говоря, ни LUA ни Python не знаю, поэтому точно сказать ничего не могу. Но я 100% уверен, что дизайнеры не рождаются со знаниями ни того, ни другого. 100% известных мне дизайнеров делятся на тех, кто вообще ни на чем программировать не умеют, и тех, кто немножечко-немножечко знает JavaScript и PHP.
Я не знаю, почему вы выбрали Lua/Python для своих скриптов. Наверное, из них легче управлять игровыми объектами, чем из С++, и они дают меньше возможностей сделать какую-нибудь катастрофическую ошибку вроде прохода по памяти, использования удаленного объекта или неудаления использованного.
E>За все современные игрушки не скажу, а у нас дела обстоят следующим образом. Есть некий самодельный инструмент — редактор уровней, главный инструмент дизайнеров. В нем можно рассмотреть игровой мир со всех сторон, подвигать объекты, поменять их свойства. Еще там же можно давать объектам на выполнение различные скрипты, тут же их править, запускать снова. E>Дизайнер может действовать так: он строит сцену из готовых объектов, настрайвает их свойства, пишет скрипты. Это обычно происходит в режиме "на паузе". После этого он сохраняет сцену, запускает ее и смотрит, что получилось. Обычно, сначала что-нибудь идет не так, как хотелось. Тогда дизайнер перегружает сцену, подправляет ее немного (передвигает неправильно стоящий объект, правит скрипт и т.д.), сохраняет, смотрит, что получилось. И т.д. и т.п. E>При этом никаких длительных перерывов в его работе нет, из редактора он не выходит. Если бы вместо скриптов была захардкоденная логика, ему пришлось бы выходить, править, перекомпилировать как минимум тот модуль, который он поправил.
Это я понимаю. Непонятно только, что в твоем понимании "захардкоденная логика". Dll на С++? Ну да, согласен. Управляемые языки могут совместить компиляцию с "сохранением сценки" так, что дизайнер ничего не заметит E>Вот о чем я пытался сказать выше. Насколько мне известо, разработка уровней организована таким образом не только у нас.
Ага, я тоже подозреваю, что вы такие не одни.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, dr.Chaos, Вы писали:
DC>Не только. Новые абстракции нужны для разбиения на части модели. Это локально снижает сложность.
А "Сложность" это что?
Подсказываю: главное уравнение общей теории поля выглядит так:
@A = 0;
Где A — некоторый вектор-потенциал, @ — некоторый дифференциальный оператор второго порядка.
Для частного случая электромагнитного поля хорошо известно, что такое A и @, и уравнение приводит к системе уравнений Максвелла (если расписать оператор даламбера и вектор-потенциал). Очевидно, в такой форме уравнение проще — в нем участвует меньше сущностей. Простота == лаконичности.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, dr.Chaos, Вы писали:
VD>>>>С++ марально устарел еще 5, а то и больше лет назад. Это здравый логический вывод. DC>>>В чем его моральная старость?
BZ>>вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет
DC>Вот, блин ты мне приведи то место где Я это сказал.
Здравствуйте, VladD2, Вы писали:
VD>Данные похожие на данные из приводимой мной презентации, но они мало что говорят об оправданности такого решения. VD>Из той же презентации видно, что на всю симуляцию игры уходит около 10% процессорного времени:
<таблицу поскипал>
Я пропустил место, где приводилась презентация. Если я правильно понимаю, поскипанная мной таблица — нечто вроде данных профайлинга, на что ушло больше процессорного времени?
Если интересно, могу привести _наши_ данные, полученные от профайлера.
Не совсем понятно, что тут понимается под симуляцией, возможно из-за того, что я не видел первоначальный пост.
VD>Из той же презентации ясно, что объе этого кода несколько больше чем объем вычислительного кода (который по всей видимости и принято считать кодом тех самых "движков"). Там указывалось, что объем вычислительного кода и объм кода симуляции написанный на С++ приблизительно одинаков 250 000 строк, но код симуляции к тому же еще содержит скрипты на языке похожем на Яву.
VD>Учитывая, что, например, дотнет если и дает проигрыш в производительности, то он все равно измеряется в процентакх, и то, что процессорные затраты на него не велики, то не кажется ли тебе не разумным писать этот код на С++? Если вместо скрипа использовать безопасный, удобный, но быстрый язык — то вы могли бы значительно упростить себе работу при этом практически ничего не потеряв в производительности.
VD>В итоге вы могли бы больше времени потратить на остальные части игры, или просто быстрее выпустить игру сделав ее при этом более надежной.
Гораздо лучше быть богатым и здоровым, чем бедным и больным
Конечно же, я с удовольствием писал бы на удобном и безопасном языке. Вопрос только в том, сколько все же составляют те самые проценты, на которые он медленнее неудобного и опасного, но более быстрого языка.
Предлагаю говорить все же более конкретно. Скажем, 10% для нас — это уже критично. У нас пока некоторые уровни на средних машинах на слайд-шоу похожи
Первые версии компилятора C++, даже с поддержкой шаблонов и исключений, были всего лишь препроцессорами, генерившими C-шный код.
Когда дело реально дошло до шаблонов, то C++ препроцессоров уже не было.
E>Ну не было у меня возможности переносить объектные файлы Turbo Pascal 3.0 с Robotron 1715 и CP/M на Turbo Pascal 5.0 на IBM XT и MS-DOS. И не знаю я про существование Turbo Pascal для SPARC-овых или MIPS-овых архитектур. Например, можно ли было tpu-файлы из Turbo Pascal на Маках использовать?
А на C++ у тебя в то время такая возможность была? Может начнём вспоминать несовместимости не только между разными платформами, но и компиляторами на одной платформе и даже разными версиями одного и того же компилятора?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, eao197, Вы писали:
E>Как утверждает Wikipedia, Borland выпускал две линейки C++ компиляторов: Turbo C++ и Borland C++.
Какие две ленейки? Был TC++ 1.0, его следущая версия была переименована в BC++ 2.0.
E>Я не уверен на счет шаблонов в Borland C++ 3.1. В Borland C++ 2.0 их точно не было.
В тройке уже были шаблоны и исключения.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Раз уж остановился здесь, то отвечу на этот пост. Прошу не воспринимать как личный выпад. Здесь я уже даже не вижу смысла разделять подветви, поскольку всеми об одном и том, только каждый в своем окружении. До тех пор пока мы не научимся абстрагировать любые вещи которыми оперируем, средствами языка, правильно, все дальнейшие мытарства — детский лепет при наличии любых языков и инструментов.
С чего все началось:
We need relatively complex language to deal with absolutely complex problems.
Это фразой сказано абсолютно все и ничего более. Эволюция только потому и появилась в нашем лексиконе, потому абсолютное совершенство недостижимо в принципе, не говоря уже об этапе рождения. Все что приходит после — лишь наследие того, что появился какой то глобальный набор задач, который требует уточнения используемых инструментов и их постепенного развития.
Чем все не закончится:
Кто то попытался, не буду повторяться, дать какое либо конечное определение сказанному и наступил кому то не туда. Извините, если попал в кого либо. "Ничего личного, только бизнес".
Далее я не приведу ни единого точного определения, поскольку эта размазанная философия уже начинает принимать угрожающий характер. Мы пытаемся разрубить то, чего не существует в принципе.
Все рождалось и развивалось в том ключе и на том этапе, когда наступал момент истины связанный с тем, что к этому как минимум были готовы морально и это можно было сформулировать в каких либо осязаемых конструкциях. Мы используем только то, до чего у нас доходят руки с учетом уровня развития. На меньше у нас не хватит сил, а на больше времени.
eao197:
И не знаю, как остальные сторонники C++ в данной ветке, но я отнюдь не утверждаю, что после C++ лучше ничего не будет. А призываю к тому, чтобы в C++ камнями перестали кидаться от нечего делать.
Вот за эту фразу я ставлю коллеге заочно 500, поскольку я со своими оценками is out of range.
BZ>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет.
А я когда пишу с применением не удовлетворяющего вас языка, то при условии правильного архитектурного рещения, у меня проблем в многопоточной среде не возникает вообще. Если ты владеешь инструментом и знаешь платформо-зависимую реализацию используемого, то язык тебе не помощник. От всех неурядиц в жизни даже мама не спасет. Что значит словосочетание километры геморроя придется искать в словаре. Мне конструкций и объектов синхронизации хватает для решения любых вопросов. Конечно язык позволяет достичь и non thread-safe реализаций, но это не значит, что меня обязывают делать именно так или язык ущербен.
Все абсолютно, не смотря на взгляды, уважаемые мною коллеги наговорили столько, что я уже перестал читать, либо по инерции это делаю из привычки или врожденного любопытства.
PS. Хотите не верить мне, просто не верьте. Когда у меня возникнут в чем либо сомнения, я сам спрошу как мне быть. Ответы без наличия знака вопроса is UB. Я до сих пор пишу на том, о чем вы догадыватесь. И не потому что боюсь учиться, а потому что инструмент позволяет сделать все что необходимо, и не только мне. В зависимости от того какими инструментами либо технологиями я владею, зависит лишь то, каков выбор будет у меня при поиске работы, НО БУДЕТ ОН ВСЕГДА!!! Может я ..., потому что везет только им, но о тех километрах которые были упомянуты, мне встречаться в жизни не приходилось, а если и так, то очень редко и решения были для меня точно достижимы. Насколько это было красиво или нет, судить только мне. Каждой задаче в зависимости от задаваемых внешних параметров свое интерфейсное средство достижения цели.
P.S. [Content — Independent] Я в этой ветке увидел лишь одно логическое завершение всего выше описанного в качестве оптимизации. Изложенное выше — лишь разложенные на много постов статьи каждого из участников, за что я люблю программирование, а за что нет. Поэтому в качестве оптимизации дерева, предлагаю сделать N количество листьев главного узла, где N= количеству участников и там каждый приведет свои за и против в протокольном формате. Все остальное ................ Вместо точек каждый определяет самостоятельно продолжение повествования.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, dr.Chaos, Вы писали:
DC>>Не только. Новые абстракции нужны для разбиения на части модели. Это локально снижает сложность. S>А "Сложность" это что? S>Подсказываю: главное уравнение общей теории поля выглядит так: S>@A = 0; S>Где A — некоторый вектор-потенциал, @ — некоторый дифференциальный оператор второго порядка. S>Для частного случая электромагнитного поля хорошо известно, что такое A и @, и уравнение приводит к системе уравнений Максвелла (если расписать оператор даламбера и вектор-потенциал). Очевидно, в такой форме уравнение проще — в нем участвует меньше сущностей. Простота == лаконичности.
Кто тут, что то про J говорил? .
В предыдущем посте я имел в виду сложность модели. А в начальном именно упрощение синтаксиса. Т.е. Понятия ООП позволили представлять более сложные модели. Немерле и ОКамл, по вашим, утверждениям служат только для уменьшения многословности, что я воспринял, как простое упрощения синтаксиса (не хочу употреблять "синтаксический сахар", а то еще один флейм поднимут ). Я прошу дать именно те абстракции которых нет в С++, но есть в Немерле/ОКамл, которые позволят мне понизить сложность при создании алгоритмов для 3Д движка.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, IT, Вы писали:
E>>Как утверждает Wikipedia, Borland выпускал две линейки C++ компиляторов: Turbo C++ и Borland C++.
IT>Какие две ленейки? Был TC++ 1.0, его следущая версия была переименована в BC++ 2.0.
Вот, что написано в Wikipedia:
Turbo C++ 3.0 was released in 1991 (shipping on November 20), and came in amidst expectations of the coming release of Turbo C++ for Microsoft Windows. Turbo C++ v3.0 first came as an MS-DOS compiler, supporting C++ templates, generation of DOS & protected mode executables, as well as generation of code targeting specific legacy CPUs, such as Intel 80186. The language implementation was updated to the latest AT&T release of C++.
After Windows 3.1 became available, Turbo C++ was sold with MS-Windows support. First Windows-based IDE was Turbo C++ 3.0 for Windows, followed by Turbo C++ 3.1 and Turbo C++ 4.5. It's possible that the jump from version 1.x to version 3.x was in part an attempt to link Turbo C++ release numbers with Microsoft Windows versions; however, it seems more likely that this jump was simply to synchronize Turbo C and Turbo C++, since Turbo C 2.0 (1989) and Turbo C++ 1.0 (1990) had come out roughly at the same time, and the next generation 3.0 was a merger of both the C and C++ compiler.
With version 3.0, Borland introduced a distinction between "Turbo C++" and "Borland C++". The former was marketed as a somewhat low-end product, while the latter was geared toward professional applications (it included additional tools and a stronger optimizer).
Т.е., как я понял, Borland продавал отдельно Turbo C++ и отдельно Borland C++.
Я по ошибке написал "выпускал" вместо "продавал".
E>>Я не уверен на счет шаблонов в Borland C++ 3.1. В Borland C++ 2.0 их точно не было.
IT>В тройке уже были шаблоны и исключения.
Вот не помню я про тройку. Поскольку, в отличии от двойки, она была исключительно Windows IDE, то у меня была возможность пользоваться ей только эпизодически. Серьезно следующую после 2.0 версию Borland-а довелось использовать только 4.0 (или какую-то ее модификацию 4.01 или 4.05) в начале 95-го и она была довольно глючная. А к концу 95-го появилась версия 4.5, в которой точно были исключения и шаблоны. И здесь в тему утверждения Wikipedia:
Version 4.0 was released in November 1993 and was notable (among other things) for its robust support of templates. In particular, it was instrumental in the development of the Standard Template Library, expression templates, and the first advanced applications of template metaprogramming.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Первые версии компилятора C++, даже с поддержкой шаблонов и исключений, были всего лишь препроцессорами, генерившими C-шный код.
IT>Когда дело реально дошло до шаблонов, то C++ препроцессоров уже не было.
Т.е. первый компилятор с поддержкой шаблонов, Cfront, за компилятор не считается?
E>>Ну не было у меня возможности переносить объектные файлы Turbo Pascal 3.0 с Robotron 1715 и CP/M на Turbo Pascal 5.0 на IBM XT и MS-DOS. И не знаю я про существование Turbo Pascal для SPARC-овых или MIPS-овых архитектур. Например, можно ли было tpu-файлы из Turbo Pascal на Маках использовать?
IT>А на C++ у тебя в то время такая возможность была? Может начнём вспоминать несовместимости не только между разными платформами, но и компиляторами на одной платформе и даже разными версиями одного и того же компилятора?
Тогда о чем мы здесь говорим?
Я так понял, что здесь сетуют, что во времена выпуска C++ 2.0 кто-то не додумал и не сделал для C++ единый формат объектных файлов и библиотек для всех компиляторов на всех платформах, а так же единый стандар формирования VMT и размещения объектов в памяти. Мол для других языков это было, а вот C++ валенки делали, они и не придумали.
Ну невозможно было сделать это для C++ ни тогда, ни сейчас. Ни по техническим, ни по политическим соображениям.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
E>>Как утверждает Wikipedia, Borland выпускал две линейки C++ компиляторов: Turbo C++ и Borland C++.
IT>Какие две ленейки? Был TC++ 1.0, его следущая версия была переименована в BC++ 2.0.
да, и потом они выпустили TC++ 3.0 как облегченную версию BC++ 3.0. в общем, по номерам версий ориентироваться в языковых фичах можно, различие между TC и BC касалось других вещей
E>>Я не уверен на счет шаблонов в Borland C++ 3.1. В Borland C++ 2.0 их точно не было.
IT>В тройке уже были шаблоны и исключения.
вот на этот счёт я могу совершенно точно ответить. в стандарте C++ 3.0 они были. в Borland C++ 3.1 были только шаблоны, и я его на этот счёт изрядно материл
Здравствуйте, eao197, Вы писали:
E>Т.е., как я понял, Borland продавал отдельно Turbo C++ и отдельно Borland C++. E>Я по ошибке написал "выпускал" вместо "продавал".
Может что-то и продавалось под другим именем, но упоминаний TC++ выше 1.0 тогда не было. В компиляторных войнах от Борланды тогда принимал участие исключительно BC++.
E>Вот не помню я про тройку. Поскольку, в отличии от двойки, она была исключительно Windows IDE
Это как? Всё там было на месте. Я писал на BC++ 3.1 с момента выхода и до самой 4.5. Писал под DOS и DPMI16.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
IT wrote: > Первые версии компилятора C++, даже с поддержкой шаблонов и исключений, > были всего лишь препроцессорами, генерившими C-шный код. > Когда дело реально дошло до шаблонов, то C++ препроцессоров уже не было.
Некоторые товарищи до сих пор preprocessor-based компиляторы поставляют.
Здравствуйте, eao197, Вы писали:
IT>>Когда дело реально дошло до шаблонов, то C++ препроцессоров уже не было.
E>Т.е. первый компилятор с поддержкой шаблонов, Cfront, за компилятор не считается?
Кто его видел этот Cfront? Вот ты, например, видел? Я Zortech видел. T/BC++ видел. VC++ видел. gcc видел. WC++ видел. Cfront не видел.
E>Я так понял, что здесь сетуют, что во времена выпуска C++ 2.0 кто-то не додумал и не сделал для C++ единый формат объектных файлов и библиотек для всех компиляторов на всех платформах, а так же единый стандар формирования VMT и размещения объектов в памяти. Мол для других языков это было, а вот C++ валенки делали, они и не придумали.
Нет, здесь сетуют не на времена выпуска C++ 2.0. А вообще на C++. Это можно было сделать и во времена C++ 1.0 и десять лет спустя. Хуже не было бы. А теперь мы, точнее вы, имеете то, что имеете.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
E>>Т.е., как я понял, Borland продавал отдельно Turbo C++ и отдельно Borland C++. E>>Я по ошибке написал "выпускал" вместо "продавал".
IT>Может что-то и продавалось под другим именем, но упоминаний TC++ выше 1.0 тогда не было. В компиляторных войнах от Борланды тогда принимал участие исключительно BC++.
+1
Я сам когда сегодня в Wikipedia прочитал, удивился. Но вот очевидцы утверждают
, что таки была еще линейка Turbo C++.
E>>Вот не помню я про тройку. Поскольку, в отличии от двойки, она была исключительно Windows IDE
IT>Это как? Всё там было на месте. Я писал на BC++ 3.1 с момента выхода и до самой 4.5. Писал под DOS и DPMI16.
В BC++ 2.0 IDE была текстовая под DOS. Хотя можно было Windows приложения под 16-бит Windows компилировать. Хотя я тогда уже вместо IDE редактор MultiEdit использовал.
В BC++ 3.1 была графическая IDE, как нормальное Windows приложение. На ней под Windows писал. Затем, с выходом, BC++ 4.0 появилась возможность 32-х битовые приложения под Windows делать, изначально мы win32s под Win 3.11 использовали.
Но вот точно помню, что поддержка исключений только в какой-то из 4-рок появилось. По крайней мере использовать исключения я начал только когда на 4.5 окончательно перебрался.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, IT, Вы писали:
IT>>>Когда дело реально дошло до шаблонов, то C++ препроцессоров уже не было.
E>>Т.е. первый компилятор с поддержкой шаблонов, Cfront, за компилятор не считается?
IT> Кто его видел этот Cfront? Вот ты, например, видел? Я Zortech видел. T/BC++ видел. VC++ видел. gcc видел. WC++ видел. Cfront не видел.
А ты в то время DEC-и видел? VAX-ы, Solaris-ы? Они же были.
К тому же мне доводилось несколько раз пользоваться C++ компиляторами, работавшими именно по принципам Cfront, вполне возможно, наследников того самого Cfront.
E>>Я так понял, что здесь сетуют, что во времена выпуска C++ 2.0 кто-то не додумал и не сделал для C++ единый формат объектных файлов и библиотек для всех компиляторов на всех платформах, а так же единый стандар формирования VMT и размещения объектов в памяти. Мол для других языков это было, а вот C++ валенки делали, они и не придумали.
IT>Нет, здесь сетуют не на времена выпуска C++ 2.0. А вообще на C++. Это можно было сделать и во времена C++ 1.0 и десять лет спустя. Хуже не было бы. А теперь мы, точнее вы, имеете то, что имеете.
Что характерно, нас это не волнует совершенно, а вот вас почему-то беспокоит
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
VD>>>Не допускаешь, что то что ты считаешь нормальным в сравнении с другим языком может оказаться ужасно сложно и медленно?
Ш>>Нет, я допускаю, что ты пытаешься подменить предмет обсуждения.
VD>Ухот от ответа можно расцнить как "да, допускаю"?
Здравствуйте, eao197, Вы писали:
E>А ты в то время DEC-и видел? VAX-ы, Solaris-ы? Они же были.
Соляру не видел. На дековском асме писал под PDP-11, даже C там какой-то ковырял. Если мне не изменяет мой склероз, то аналогами VAX были наши СМ ЭВМ. ЕС ЭВМ были содраны с IBM 360. Этих монстриков тоже довелось пощупать.
IT>>Нет, здесь сетуют не на времена выпуска C++ 2.0. А вообще на C++. Это можно было сделать и во времена C++ 1.0 и десять лет спустя. Хуже не было бы. А теперь мы, точнее вы, имеете то, что имеете.
E>Что характерно, нас это не волнует совершенно, а вот вас почему-то беспокоит
Бывает. Видимо я (мы) слишком чувствительны и восприимчивы к тому, что на нас как на пользователей так долго и так нагло кладёт комитет. У нас со временем это стало обоюдным. Ну а вас это не волнует совершенно. Понимаю.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Нет, здесь сетуют не на времена выпуска C++ 2.0. А вообще на C++. Это можно было сделать и во времена C++ 1.0 и десять лет спустя. Хуже не было бы. А теперь мы, точнее вы, имеете то, что имеете.
E>>Что характерно, нас это не волнует совершенно, а вот вас почему-то беспокоит
IT>Бывает. Видимо я (мы) слишком чувствительны и восприимчивы к тому, что на нас как на пользователей так долго и так нагло кладёт комитет. У нас со временем это стало обоюдным. Ну а вас это не волнует совершенно. Понимаю.
Сколько сарказма
Тема, я думаю исчерпана.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Alexmoon, Вы писали:
A>Здравствуйте, BulatZiganshin, Вы писали:
A>Раз уж остановился здесь, то отвечу на этот пост. Прошу не воспринимать как личный выпад.
тут проблема скорее в противоположном — чтоб мои слова не воспринимались слишком близко к сердцу
A>С чего все началось: A>
A>We need relatively complex language to deal with absolutely complex problems.
A>Это фразой сказано абсолютно все и ничего более. Эволюция только потому и появилась в нашем лексиконе, потому абсолютное совершенство недостижимо в принципе, не говоря уже об этапе рождения. Все что приходит после — лишь наследие того, что появился какой то глобальный набор задач, который требует уточнения используемых инструментов и их постепенного развития.
представьте себе ассемблер с ООП расширениями, шаблонами, клозурами, монадами, примитивами синхронизации и т.д. смешно? было бы смешно, если б не было близко к правде. С появился как язык системного программирования, высокоуровневый ассемблер, и именно благодаря своей эффективности, близости к железу он завоевал симпатии в мире ранних мини-компьютеров и персоналок, с их скромными ресурсами
в 80-х было три конкурирующих языка процедурного программирования — С, паскаль, модула-2. для прикладного программирования наилучшим, имхо, была модула. в области ООП были представлены Эйфель, С++ и Objective C. Objective C предлагал компонентное программирвоание (кто-то здесь ругался на то, что его не "догадались" сделать в С++), Eiffel на мой взгляд — это вообще референсный компилируемый ООП язык
выиграли соревнование парочка С/С++. почему? имхо потому, что во-первых они обеспечивали обратную совместимость (в отличие от идеальной на мой взгляд пары Модула/Эйфель), во-вторых народ тогда ещё беспокоился об эффективности и ObjC с его всегда динамическим связыванием выглядел подозрительно
последние 15 лет С++ развивается только в направлении усиления шаблонов (можете поправить меня — тут я не гуру), т.е. всё той же идеи наиболее высокоуровневой записи высокоэффективного кода. ну и учитывая прогресс в области оптимизации, сейчас С++ является наиболее высокоуровнеым способом написать код, который будет не медленней ассемблерного. и это здорово
однако когда речь доходит ло прикладного программирования и эффективность оказывается не главным, тут С++ напоминает Винни-Пуха, который прикидывался тучкой в языке нет GC и type-safe generic references, синхронизации, клозур и т.п. ну и фиг с ним! мы всё это сэмулируем! в результате чего есть язык С++, содержащий массу конструкций, которые прикладному программисту просто не следует использовать, и многочисленные бибилиотеки, которые худо-бедно эмулируют возможности, напрямую встроенные в другие, более современные языки
вот поэтому вы и need a complex language — чтобы созранить совместимость с кодом 30-летней давности, сгенерить как можно более эффективную программу, а затем попытаться как-то сэмулировать современные языки. что из этого получается, можно охарактеризовать далогом из моей переписки:
— пробовал я эти lazy evaluation да higher-order funcs. фигня, код даже для простых вещей получается сложным и неудобочитаемым
— а какой язык ты пробовал?
— какой язык? они же в boost есть!
я тут выше приводил пару примеров кода в хаскел, напиши их аналоги в С++ и сравни сам. если вместо изучения всех этих legacy features и методов эмуляции modern features изучать напрямую современный язык, то ты здорово сэконишь во времени изучения и затем во времени написания/отладки кода. но понятное дело, что если ты уже 15 лет живёшь с С++ и занешь его до тонкостей, то возможность другого человека лёгким движением руки достичь аналогичной квалификации кажется тебе чем-то неправильным и поневоле начинаешь искать контраругменты. я лично всегда интересовался ЯП и знаю их до чёрта, поэтому меня углубление в детали в С++ давно перестало интересовать, ещё со второй версии языка с её немерянными правилами относительно множ наследования
A>
BZ>>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет.
A>А я когда пишу с применением не удовлетворяющего вас языка, то при условии правильного архитектурного рещения, у меня проблем в многопоточной среде не возникает вообще. Если ты владеешь инструментом и знаешь платформо-зависимую реализацию используемого, то язык тебе не помощник. От всех неурядиц в жизни даже мама не спасет. Что значит словосочетание километры геморроя придется искать в словаре. Мне конструкций и объектов синхронизации хватает для решения любых вопросов. Конечно язык позволяет достичь и non thread-safe реализаций, но это не значит, что меня обязывают делать именно так или язык ущербен.
именно об этом я и говрю — что в С++ thread-safe программирование требует специального изучения и в job offers, например, указывается как отдельное требование чтобы понять, насколько это смешно, представьте себе скажем требование "умение вызывать функции рекурсивно". это тоже может специальным умением в языке типа Фортрана, где это не поддерживалось
т.е. опять речь о complex language, порождённом тем, что современные концепции программирования в нём — нечто дополнительно прикрученное сбоку с теми самыми километрами художеств
ps: кстати, насчёт +500 — мне счас пришло в голову, что принятая на этом форуме система оценки поощряет конформизм, в частности поощряет сторонников mainstream языков программирования
Здравствуйте, BulatZiganshin, Вы писали:
BZ>однако когда речь доходит ло прикладного программирования и эффективность оказывается не главным, тут С++ напоминает Винни-Пуха, который прикидывался тучкой в языке нет GC и type-safe generic references, синхронизации, клозур и т.п. ну и фиг с ним! мы всё это сэмулируем! в результате чего есть язык С++, содержащий массу конструкций, которые прикладному программисту просто не следует использовать, и многочисленные бибилиотеки, которые худо-бедно эмулируют возможности, напрямую встроенные в другие, более современные языки
BZ>вот поэтому вы и need a complex language — чтобы созранить совместимость с кодом 30-летней давности, сгенерить как можно более эффективную программу, а затем попытаться как-то сэмулировать современные языки. что из этого получается, можно охарактеризовать далогом из моей переписки:
Имхо, в этом и есть главная причина недопонимания собеседников. Почему-то считают, что в исходной фразе под 'absolutely complex problems' подразумевают абсолютно любые сложные задачи. Если же, к примеру, ограничить контекст сложными задачами в области системного программирования, тогда ситуация станет более реальной.
Вот к примеру, требуется GUI программка для on-line мониторинга сотни-полутора параметров с дальнейшим привязыванием к этому мониторингу трендов, звуковой сигнализации и пр. И чтобы для каждого параметра можно было задавать свои правила обработки. И чтобы работая в фоне отжирала не более 10%-15% процентов процессорного времени. И памяти не больше десятка-другого мегабайт. Бах -- и задача из простой превращается в сложную.
Или, скажем, приложение, которое разбирает и перемаршрутизирует трафик с сотнями/тысячами пакетов по каждому соединению. И соединений по несколько десятков. И временами интересные эффекты на уровне сетевого стека начинают происходить (к примеру, соединение умирает, а через select это не видно, как будто сокет жив и здоров). И опять, из простой по логике задача превращается в сложную по исполнению из-за своих условий.
Так что есть еще место для объектно-ориентированного почти ассемблера с шаблонами и исключениями (но без замыканий, монад, примитивов синхронизации и прочего).
По поводу применимости C++ в прикладных областях и по поводу прикручивания в C++ lazy evaluation и high order funcs я с вами согласен.
PS.
BZ>ps: кстати, насчёт +500 — мне счас пришло в голову, что принятая на этом форуме система оценки поощряет конформизм, в частности поощряет сторонников mainstream языков программирования
Вообще-то на моей памяти максимальные оценки здесь получали как раз внезапно появляющиеся адепты функционального программирования, которые начинали рассказывать разные необычные для mainstream-программистов вещи.
PPS.
Eiffel действительно замечательный язык. Но, имхо, загубил его маркетинг.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Вот к примеру, требуется GUI программка для on-line мониторинга сотни-полутора параметров с дальнейшим привязыванием к этому мониторингу трендов, звуковой сигнализации и пр. И чтобы для каждого параметра можно было задавать свои правила обработки. И чтобы работая в фоне отжирала не более 10%-15% процентов процессорного времени. И памяти не больше десятка-другого мегабайт. Бах -- и задача из простой превращается в сложную.
по-моему, здесь неправильная постановка эту вот хрень надо определённо разделить на сервер и морду
E>Или, скажем, приложение, которое разбирает и перемаршрутизирует трафик с сотнями/тысячами пакетов по каждому соединению. И соединений по несколько десятков. И временами интересные эффекты на уровне сетевого стека начинают происходить (к примеру, соединение умирает, а через select это не видно, как будто сокет жив и здоров). И опять, из простой по логике задача превращается в сложную по исполнению из-за своих условий.
очень хорошо решается на эрланг. здесь даже job offer есть с такой примерно фразой — "покажем, что не только Ericson умеет надёжэные распределённые системы на эрланге писать!" кстати, может и предыдущая задача к нему подходит? по крайней мере, правила обработки приятней писать на эрданге, нежели изобретать свой язык
BZ>>ps: кстати, насчёт +500 — мне счас пришло в голову, что принятая на этом форуме система оценки поощряет конформизм, в частности поощряет сторонников mainstream языков программирования
E>Вообще-то на моей памяти максимальные оценки здесь получали как раз внезапно появляющиеся адепты функционального программирования, которые начинали рассказывать разные необычные для mainstream-программистов вещи.
меня определённо ждёт успех!
E>Eiffel действительно замечательный язык. Но, имхо, загубил его маркетинг.
а имхо дело было именно в том, что он не предлагал постепенной миграции, как C++. C и C++ в конце 80-х как бы взаимно усиливали позиции друг друга. первый был популярен потому, что с него легко можно было перейти на ООП язык (а ООП было coined уже тогда, хотя приличных компиляторов ещё не было), а С++ — потому, что на него легко было переходить с С
Здравствуйте, BulatZiganshin, Вы писали:
E>>Вот к примеру, требуется GUI программка для on-line мониторинга сотни-полутора параметров с дальнейшим привязыванием к этому мониторингу трендов, звуковой сигнализации и пр. И чтобы для каждого параметра можно было задавать свои правила обработки. И чтобы работая в фоне отжирала не более 10%-15% процентов процессорного времени. И памяти не больше десятка-другого мегабайт. Бах -- и задача из простой превращается в сложную.
BZ>по-моему, здесь неправильная постановка эту вот хрень надо определённо разделить на сервер и морду
Речь идет именно о морде.
Существующая морда написана в лоб и слишком прожорлива. Сейчас приходится многое переделывать, чтобы удовлетворить поставленным условиям.
E>>Или, скажем, приложение, которое разбирает и перемаршрутизирует трафик с сотнями/тысячами пакетов по каждому соединению. И соединений по несколько десятков. И временами интересные эффекты на уровне сетевого стека начинают происходить (к примеру, соединение умирает, а через select это не видно, как будто сокет жив и здоров). И опять, из простой по логике задача превращается в сложную по исполнению из-за своих условий.
BZ>очень хорошо решается на эрланг. здесь даже job offer есть с такой примерно фразой — "покажем, что не только Ericson умеет надёжэные распределённые системы на эрланге писать!" кстати, может и предыдущая задача к нему подходит? по крайней мере, правила обработки приятней писать на эрданге, нежели изобретать свой язык
Сильно сомневаюсь в производительности erlang-овского решения. В задаче нужно не только разбирать и перемаршрутизировать, но и некоторую обработку делать. В довольно ограниченных, опять же, ресурсах.
E>>Вообще-то на моей памяти максимальные оценки здесь получали как раз внезапно появляющиеся адепты функционального программирования, которые начинали рассказывать разные необычные для mainstream-программистов вещи.
BZ>меня определённо ждёт успех!
Желаю удачи!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
май 90 — tc++ 1.0 (кстати, одновременно с drdos 5.0 и win 3.0)
три месяца спустя — 1.01
февраль 91 — bc++ 2.0 с поддержкой программирования под винды (просто sdk туда включили). кстати, полная исталляция — 17 мег, что на 40-никах тогдагних времён смотрелось sexy
ноябрь 91 — tc++/dos 3.0 и tc++/win 3.0. каждый содержал среду и библиотеки только для одной платформы
июнь 92 — bc++ 3.1 (среда и библиотеки для обоих платформ плюс dpmi-16)
как вилите, настоящая чехарда. они позиционировали BC как платформу для профессионалов, с большей ценой, поэтому tc и bc продавались параллельно, но новые версии выпускались не синхронно
tc101 и bc31 у меня есть. в последнем точно есть темплейты. НО — в ходе развития C++ темплейты непрервыно разивались, так что неудивительно, что в 4.0 они стали более продвинутыми и т.д.
Здравствуйте, dr.Chaos, Вы писали:
BZ>>преимущества Хаскела — очень строгая типизация, отлавливающая большинство ошибок с типами, и лёгкость конструирования алгоримтов из составных частей. я не представляю себе потребности игр, но вот к примеру печать простых чисел:
DC>Жаль у меня нет куска кода для оптимизации сцены при преобразовании во внутренний формат движка . Могли бы провести эксперимент .
я тоже могу привести свой код, но смысл? я специально привёл маленькие примеры, которые позволяют увидеть экспрессивную мощь ФП. для любой обработки данных (с которой я встречался) ф.п. упрощает дело. и чем сложнее алгоритмы, тем больше ты выигрываешь. НО — это работает медленней, чем императивнй код
BZ>>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет
E>Я постоянно пишу многопоточные программы на C++ и проблем с синхронизаций практически не возникает. Потому что специально заточенным для этого инструментом пользуюсь. Так что функциональность или императивность языка здесь дело далеко не принципиальное.
разница в том, что ты поьзуешься специальным инструментом, который потребовал специального изучения, а я первые 8 месяцев вообще ничего не делал. оно просто работало ввиду отсутствия расшаренных ресурсов. потом такой ресурс появился и я добавил к нему locking. it's all. поэтому я и утверждаю, что сложность С++ вызвана его попыткой быть одновременно и эффективным никзоурневым языком, и языком прикладного программирования и обилием legacy features, а не сложностью типичных решаемых задач
Здравствуйте, BulatZiganshin, Вы писали:
BZ>тут проблема скорее в противоположном — чтоб мои слова не воспринимались слишком близко к сердцу
Я как раз близко к сердцу и не воспринимал, но раз дискуссия продолжается теми аргументами, которые есть, значит кто то все таки это воспринимает именно так
BZ>представьте себе ассемблер с ООП расширениями, шаблонами, клозурами, монадами, примитивами синхронизации и т.д. смешно? было бы смешно, если б не было близко к правде. С появился как язык системного программирования, высокоуровневый ассемблер, и именно благодаря своей эффективности, близости к железу он завоевал симпатии в мире ранних мини-компьютеров и персоналок, с их скромными ресурсами
Теперь не применительно только к этой фразе а вывод в общем. Каждый инструмент создается as main concept для определенных задач. Кто то ниже говорил "разделять сервер и морду". Я совершенно с этим согласен и как видишь даже в бессмысленный спор не вступаю. Вопрос лишь в том кто будет морду реализовать.
Я прекрасно представляю ассемблер с шаблонами и примитивами синхронизации, но и вы представте C# в виде монстра, который решает не только задачи прикладного програмирования, а еще и будет перекручен конструкциями с определенными unmanaged оговорками для свободного манипулирования ресурсами под уровень ядра, либо все таки МС придется извратится чтобы все возможные варианты изобразить MSIL компилером. Все равно это будут не логичные для его контекста описания. Вообщем заметьте Г. получается как с одной, так и с другой стороны. Не нужно все это.
Пускай C++ занимается задачами в своем стиле и не нужно ему всего что касается managed расширений. Человек, который не хочет следить за ресурсами сам, либо не умеет оперировать типами, пускай не лезет в ++ (это не характеризует недостатки языка). При правильном архитектурном подходе, я поверь мне уже практически избавился от страшных снов связанных с этим, абсолютно. Каждый инструмент требует определенных навыков, опыта и мозгов. Кесарю, кесарево. Железная истина. Для прикладников языки другие.
BZ>в 80-х ...
Хватит о них. Мне 33 и я помню о них прекрасно. По моему до сих пор в обсуждении остались только люди, которые хоть как то ориентируются во всем этом флейме, не воспримите за оскорбление.
BZ>последние 15 лет С++ развивается только в направлении усиления шаблонов.
За исключением доработки в сторону узких мест — ты совершенно прав. Метапрограммирование — это следующий шаг развития.
BZ>однако когда речь доходит ло прикладного программирования и эффективность оказывается не главным, тут С++ напоминает Винни-Пуха, который прикидывался тучкой в языке нет GC и type-safe generic references, синхронизации, клозур и т.п. ну и фиг с ним! мы всё это сэмулируем! в результате чего есть язык С++, содержащий массу конструкций, которые прикладному программисту просто не следует использовать, и многочисленные бибилиотеки, которые худо-бедно эмулируют возможности, напрямую встроенные в другие, более современные языки
Вот и пускай будут они туда встроены. !!!! О БОЖЕ, мы наконец приходим к тому, к чему с самого начала стремились.
1. Я счастлив, что простому прикладнику наконец сделали инструменты, которые позволяют меньше думать и больше работать, но это отнюдь не означает что С++ плох. Ему просто все эти расширения не нужны.
2. Если человек владеет С++ — это должно четко обозначать что он в состоянии за время не меньшее, чем прикладник с помощью своего инструмента, может эмулировать все те вещи о которых мы говорим.
Для меня это кристальная истина. Все остальные лишь используют язык, в каких то узких целях, который им возможно и не нужен.
В языке достаточно минимально необходимых примитивов для эмуляции чего угодно. Все что нельзя сделать, неправильно концептуально спроектировано
То что язык развивается в сторону метапрограммирования на базе шаблонов — это совершенно логичесное и естественное развитие языка данного уровня.
BZ>вот поэтому вы и need a complex language — чтобы созранить совместимость с кодом 30-летней давности, сгенерить как можно более эффективную программу, а затем попытаться как-то сэмулировать современные языки.
Что вы так пристали к этой совместимости. Она остается до сих пор только потому, что нет смысла язык наворачивать не свойственными ему вещами изначально.
Если для вас совместимость главный критерий, то для меня абсолютно. Я уже ранее говорил, что в определеной степени владения языком нет проблем в эмуляции того о чем мы говорим. Просто кто то — это сделает быстрее, а кто то не сделает вообще и то что язык требует более высокого уровня skills — это не недостаток его, а лишь характеристика.
BZ>я тут выше приводил пару примеров кода в хаскел, напиши их аналоги в С++ и сравни сам. если вместо изучения всех этих legacy features и методов эмуляции modern features изучать напрямую современный язык, то ты здорово сэконишь во времени изучения и затем во времени написания/отладки кода.
может ведь и не хватить мозгов ее отладить даже в такой среде. все относительно.
на времени обучения сильно сэкономишь, но сильно проиграешь в развитии и гибкости.
BZ>именно об этом я и говрю — что в С++ thread-safe программирование требует специального изучения и в job offers, например, указывается как отдельное требование чтобы понять, насколько это смешно, представьте себе скажем требование "умение вызывать функции рекурсивно". это тоже может специальным умением в языке типа Фортрана, где это не поддерживалось
Сравнивать "рекурсивный вызов" и "thread-safe" — это все равно что в правах на вождение автомобиля указывать уровень владения самокатом. Давайте не опускаться до такого уровня. Человек ничего не знающий о потоках и разделяемых ресурсах и в C# репу перегреет такими понятиями как ThreadMutex и т.д.
BZ>т.е. опять речь о complex language, порождённом тем, что современные концепции программирования в нём — нечто дополнительно прикрученное сбоку с теми самыми километрами художеств
Где явное определение того, что так называемый complex language охватывает весь спектр современных концепций и что есть весь спектр современных концепций?
Я надеюсь понятно без лишних объяснений почему вам не удастся быть объекивных в этой части вопроса.
Здравствуйте, eugene0, Вы писали:
E>Зачем что-то колбасить? Вот LUA, вот python. Для того, чтобы делать что-то новое, нужно, чтобы это новое было чем-то лучше, чем готовое и многократно использованное и оттестированное старое. Чем вот эти псевдоязыки были бы лучше?
А всем ли хорош Python. Если дизайнер совершит ошибку (переменную одного типа присвоит переменной другого типа), то эта ошибка выявится только после прогона сценки по всевозможным сценариям, причём, возможно, ошибка выявляется в уж очень редких случаях. Вот в Nemerle нет такого фатального преимущества, потому он лучше.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну а Боинг, Локхид и Туполев продолжают своими делами заниматься — изготовляют качественные самолеты. И с некоторым удивлением смотрят на это авиамоделирование
Профессиональные лучники, годами оттачивавшие мастерство и способные эффективно поражать цели на расстоянии в 200 метров, тоже долго с умилинем поматривали на крестьян с пороховыми пукалками, которые могли стрелять на 50 метров, имели малую убойную силу и долгое-долгое время перезарядки. Но зато не требовали обучения.
Однако лучники — они ведь настоящие мастера, им всегда рады в любой армии мира
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, BulatZiganshin, Вы писали:
E>>>Вот к примеру, требуется GUI программка для on-line мониторинга сотни-полутора параметров с дальнейшим привязыванием к этому мониторингу трендов, звуковой сигнализации и пр. И чтобы для каждого параметра можно было задавать свои правила обработки. И чтобы работая в фоне отжирала не более 10%-15% процентов процессорного времени. И памяти не больше десятка-другого мегабайт. Бах -- и задача из простой превращается в сложную.
BZ>>по-моему, здесь неправильная постановка эту вот хрень надо определённо разделить на сервер и морду
E>Речь идет именно о морде. E>Существующая морда написана в лоб и слишком прожорлива. Сейчас приходится многое переделывать, чтобы удовлетворить поставленным условиям.
когда ресурсы критичны, определённо ничего лучше С++ не сделаешь. но — может проблема была именно в некомпетентности тех программистов? у меня в программе есть вещи, которые работают быстрее, чем у конкурентов на С++. и не потому, что я волшебник, а потому, что они используют более простые алгоритмы. более высокий уровень языка даёт возможность больше времени потратить на алгоритмическую оптимизацию. и делать это, заметим, интереснее, чем писать низкоуровневый код
у них скорость сервера получилась сравнимой с апачем, правда имхо за счёт того, что они использовали light-weight threads, а апач тогда — нет
E>>>Или, скажем, приложение, которое разбирает и перемаршрутизирует трафик с сотнями/тысячами пакетов по каждому соединению. И соединений по несколько десятков. И временами интересные эффекты на уровне сетевого стека начинают происходить (к примеру, соединение умирает, а через select это не видно, как будто сокет жив и здоров). И опять, из простой по логике задача превращается в сложную по исполнению из-за своих условий.
BZ>>очень хорошо решается на эрланг. здесь даже job offer есть с такой примерно фразой — "покажем, что не только Ericson умеет надёжэные распределённые системы на эрланге писать!" кстати, может и предыдущая задача к нему подходит? по крайней мере, правила обработки приятней писать на эрданге, нежели изобретать свой язык
E>Сильно сомневаюсь в производительности erlang-овского решения. В задаче нужно не только разбирать и перемаршрутизировать, но и некоторую обработку делать. В довольно ограниченных, опять же, ресурсах.
а вы в курсе, что эрланг был создан Эриксоном как раз для программирования своих АТСок? в том числе и очень больших. он компилируется, хотя как динамический язык он конечно не может быть столь быстрым, как С++ и даже наверно Ява. с другой стороны, обработку можно делать вызовами сишных функций — каждому своё, как было написано на входе в какой-то концлагерь
вот мой собственный пример. я пишу архиватор. там проихводительность критична так же, как скажем и в играх: 10% — это уже заметная разница. НО — свою программу я чётко разделил на две части: библиотеки сжатия и всё остальное. библиотеки написаны на С++ и по большой части не мной. мне же остаётся только дирижирование всем этим оркестром. так что я не теряю ни в скорости, ни в удобстве программирования. память была проблемой, но сейчас по памяти я даже обхожу некоторых конкурентов. почему? потому, что они хранят в памяти имена файлов целиком (это основные затраты памяти), а я — отдельно имя каталога (оно одно на 10-15 файлов) и отдельно имя внутри каталога. и сливаю их только при использовании. можно такое сделать в C++ (на котором написаны другие арзиваторы) с GC? можно, но сделано только в одном
Здравствуйте, eugene0, Вы писали:
E>Создать столько юнитов, конечно, не проблема. Но представь себе, что каждый из этих юнитов есть интерпретатор или виртуальная машинка, выполняющая скрипт и все это одновременно.
А это и не нужно. Ни один С++ не позволит наделить тысячи объектов сложной логикой. Если их много, то они по пределению будут тупы.
Вспомни монстров дума и ботов Q3.
E>В играх скрипт по сравнению с С++ и другими языками дает обычно два приемущества: E>1) в скриптах как правило не пишется архитектурно сложного кода, поэтому их пишут не программисты, а дизайнеры миссий/уровней/карт, которые в силу специфики своей работы скриптовыми языками владеют, а С++ и Немерле — нет.
И все же, чем же Немерле тут будет отличаться от скрипта? Разве что тем, что кроме примитивного кода, он все же позволит писать и довольно сложный. Ну, так это приемущество.
E>2) когда логика поведения юнитов написана на скриптах, дизайнер может менять ее без перекомпиляции кода. На самом деле ему вообще не нужны исходники игры, хватит исполняемых файлов.
Устроить незаметную для глаза компиляцию скрипта во время его записи нет проблем. И менять его тоже будет просто.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eugene0, Вы писали:
E>Зачем что-то колбасить? Вот LUA, вот python. Для того, чтобы делать что-то новое, нужно, чтобы это новое было чем-то лучше, чем готовое и многократно использованное и оттестированное старое. Чем вот эти псевдоязыки были бы лучше?
Дык, на вопрос "зачем" как раз ответ ясен. Ты получаешь мощь выше чем в Питоне со скоростью сравнимой с С++.
E>Дизайнер может действовать так: он строит сцену из готовых объектов, настрайвает их свойства, пишет скрипты. Это обычно происходит в режиме "на паузе". После этого он сохраняет сцену, запускает ее и смотрит, что получилось. Обычно, сначала что-нибудь идет не так, как хотелось. Тогда дизайнер перегружает сцену, подправляет ее немного (передвигает неправильно стоящий объект, правит скрипт и т.д.), сохраняет, смотрит, что получилось. И т.д. и т.п.
Сам игрался с редакторами к размы играм, например, к ФарКраю, и представлю это.
E>При этом никаких длительных перерывов в его работе нет, из редактора он не выходит. Если бы вместо скриптов была захардкоденная логика, ему пришлось бы выходить, править, перекомпилировать как минимум тот модуль, который он поправил.
Дык о том и речь. Только сегодня вместо скриптов можно использоать более мощьные языки. Причем, что забано само ядро игры можно писать на них же и тлько откровенно тонкие части оптииизировать на низкоуровенвых языках.
E>Вот о чем я пытался сказать выше. Насколько мне известо, разработка уровней организована таким образом не только у нас.
Естественно. Вопрос тольк в том, зачем там скрипты и С++. Первое порождает медленный результат и чревато багами отлавиливаемыми только в рантайме, а второе очень медленно в разработке и чревато трудно уловимыми багами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eugene0, Вы писали:
E>Здравствуйте, VladD2, Вы писали:
VD>>Данные похожие на данные из приводимой мной презентации, но они мало что говорят об оправданности такого решения. VD>>Из той же презентации видно, что на всю симуляцию игры уходит около 10% процессорного времени: E><таблицу поскипал>
E>Я пропустил место, где приводилась презентация.
Нет совесм, это оценки авторов Анрыла. Там не только процессороное время.
E>Если интересно, могу привести _наши_ данные, полученные от профайлера.
Конечно интересно.
E>Конечно же, я с удовольствием писал бы на удобном и безопасном языке. Вопрос только в том, сколько все же составляют те самые проценты, на которые он медленнее неудобного и опасного, но более быстрого языка.
Хохма заключается в том, что величина эта переменная и обычно она не превышает статистической пограшности. Алгоритмические просчеты или просто выбор не оптимальных путей дает куда больший проигрышь. Единственное что действительно приносится в жертву — это расходуемая память. GC показывает хорошую скорость только если занимает память с запасом. Плюс есть собсвтенные накладные расходы. Так что получается, что расход памяти у дотнета на уровне скриптовых языков.
E>Предлагаю говорить все же более конкретно. Скажем, 10% для нас — это уже критично. У нас пока некоторые уровни на средних машинах на слайд-шоу похожи
Дык. Тут уже язык мало что може сделать. Тут нужна или акселерация, или изменение алгоритмов. А на них нужно время. А оно уходит на больрбу с С++. Идея ясна?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>когда ресурсы критичны, определённо ничего лучше С++ не сделаешь. но — может проблема была именно в некомпетентности тех программистов?
Программисты те, которые есть. Очень даже не плохие. И времени на решение задач, как всегда не много. Поэтому было сделано так, как было, в отведенное время уложились, результат получили. Теперь с ростом объемов результат
оказывается неудовлетворительным.
Что до Erlang-а, то мы запустили свои решения в работу уже N лет назад, а про Erlang я услышал в первый раз здесь года два тому. Такое невежество может и не делает мне чести, однако это реальность. И существующие C++ продукты гораздо дешевле сейчас сопровождать и развивать, чем переписывать на чем-то другом.
Вообще же это уже начинается оффтопик. Любую задачу можно успешно решать разными инструментами. Важно, чтобы руки были правильные и инструмент хорошо в руку ложился. Не знаю как где, но в наших условиях человека гораздо проще научить программировать на C++ в стиле C with classes, чем на Erlang или Haskell. Это тоже, к сожалению (или к счастью) реальность, с которой приходится считаться.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Alexmoon, Вы писали:
A>Я прекрасно представляю ассемблер с шаблонами и примитивами синхронизации, но и вы представте C# в виде монстра, который решает не только задачи прикладного програмирования, а еще и будет перекручен конструкциями с определенными unmanaged оговорками для свободного манипулирования ресурсами под уровень ядра,
Думаю, что для уровня ядра в качестве переносимого высокоуровнего ассемблера лучше подойдёт C, а не C++.
BZ>>последние 15 лет С++ развивается только в направлении усиления шаблонов.
A>За исключением доработки в сторону узких мест — ты совершенно прав. Метапрограммирование — это следующий шаг развития.
С одной оговоркой. Метопрограммирование на шаблонах — это тупиковая ветвь развития человечества.
A>В языке достаточно минимально необходимых примитивов для эмуляции чего угодно. Все что нельзя сделать, неправильно концептуально спроектировано
Мне очень нравится декларативная составляющая современных языков. Не мог бы ты сэмулировать на C++ атрибуты?
A>То что язык развивается в сторону метапрограммирования на базе шаблонов — это совершенно логичесное и естественное развитие языка данного уровня.
Ничего логичного и естетсвенного. Метапрограммирование на шаблонах — это высокоинтеллектуальное извращение. А извращение не может быть естественным. Даже высокоинтеллектуальное.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
E>>Речь идет именно о морде. E>>Существующая морда написана в лоб и слишком прожорлива.
IT>Т.е. прожорливые морды можно писать и на плюсах?
Я когда-нибудь утверждал обратное?
Тем более, что на плюсах получилась прожорливая, но работающая. А на Java была бы и прожорливая и тормознутая.
А на C# была бы только под Windows.
В общем, есть из чего выбрать.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
BZ>>когда ресурсы критичны, определённо ничего лучше С++ не сделаешь. но — может проблема была именно в некомпетентности тех программистов?
E>Программисты те, которые есть. Очень даже не плохие. И времени на решение задач, как всегда не много. Поэтому было сделано так, как было, в отведенное время уложились, результат получили. Теперь с ростом объемов результат E>оказывается неудовлетворительным.
я только в том смысле, что может, эта задача не так уж критична по времени/памяти, и при прямых руках её и на более высокоуровневом языке можно сделать, уложившись в требования. и при этом сэкономить время
E>Что до Erlang-а, то мы запустили свои решения в работу уже N лет назад, а про Erlang я услышал в первый раз здесь M лет назад,
так звучит лучше
E>Такое невежество может и не делает мне чести, однако это реальность. И существующие C++ продукты гораздо дешевле сейчас сопровождать и развивать, чем переписывать на чем-то другом.
E>Вообще же это уже начинается оффтопик. Любую задачу можно успешно решать разными инструментами. Важно, чтобы руки были правильные и инструмент хорошо в руку ложился. Не знаю как где, но в наших условиях человека гораздо проще научить программировать на C++ в стиле C with classes, чем на Erlang или Haskell. Это тоже, к сожалению (или к счастью) реальность, с которой приходится считаться.
более того — для Хаскела до сих пор нет ни одной книги типа "Haskell in real world", а некоторые элементарнейшие библиотеки типа сериализации мне пришлось писать самому. т.е. практика такова, что в этот вагон не стоит спешить. кстати, вышеупомянутая позиция с эрлангом — вообще, первая FP позиция, которую я увидел в нашей стране
года 4 назад я тусовался в ruby тусовке, которая находилась в таком же состоянии и мечтала о killer app. недавно я увидел, что в одессе ищут человека на ruby rails т.е. у них такой killer app всё же появился, и одно время, я слышал, большую часть сообщений в ruby-talk занимало именно обсуждение rails ну то есть потом для него создали отдельную эху
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А самолет, который я описал, движется ? Да. Летает со скоростью 100 км/час. И даже, может, и не падает. Жрет горючее как 100 Боингов, но летает
PD>Ну и счастливого полета на этом качественном самолете. В соседнюю деревню, За рогами и копытами.
Если до соседней деревни 15 километров, то скорости в 100км/ч за глаза хватит. Если горючего так же в избытке — то такой самолет можно применять, зачем что-то другое искать? Оно же ведь наверняка еще и больше денег стоить будет, за эффективность-то?
Здравствуйте, eao197, Вы писали:
E>Сколько сарказма
Это правда жизни.
E>Тема, я думаю исчерпана.
Для меня тема C++ исчерпана давно. Если бы некоторые индивидуумы всерьёз не считали бы C++ "сложным языком для сложных программ" и не пудрили периодически здесь мозги другим, то я бы о нём уже давно забыл.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, eao197, Вы писали:
E>Имхо, в этом и есть главная причина недопонимания собеседников. Почему-то считают, что в исходной фразе под 'absolutely complex problems' подразумевают абсолютно любые сложные задачи. Если же, к примеру, ограничить контекст сложными задачами в области системного программирования, тогда ситуация станет более реальной.
Тогда слова не будут восприниматься откровенным бредом и надменной наглостью, но спорности они все равно не потеряют.
Так к системным задачам традиционно относят компиляторы, но любой кто более менее знает Лисп, Хаскель, ОКамл... Немерле в конце концом понимает, что писать компиляторы на С++ весьма не разумное решение.
Что касается задач вроде дравйверов. Конечно! Конечно если сама ОС написана на С и у нее C API, драйверы работают в нулевом кольце защиты... то и думать нечего о написании драйверов на чем-то более продвинутом. Но ведь и ОС может быть другой! Блин, когда ОС вроде Сингулярити будет доступна смернным?!
E>Вот к примеру, требуется GUI программка для on-line мониторинга сотни-полутора параметров с дальнейшим привязыванием к этому мониторингу трендов, звуковой сигнализации и пр. И чтобы для каждого параметра можно было задавать свои правила обработки. И чтобы работая в фоне отжирала не более 10%-15% процентов процессорного времени. И памяти не больше десятка-другого мегабайт. Бах -- и задача из простой превращается в сложную.
Забыл добавить "... на С++". Иначе это не так верно. Замечательный пример обратного я скачал буквально недвано. BitTorrent. Программа написана на Питоне и офигительно качает себе в бэкграуде тонны файлов. Ну, да, жрет она 40 метров на моей машине. Ну, и фиг с ними! За-то она не вылетает, не глючит, проста и удобна в использовании, ставится в одно касание.
И это на тормозном Питоне! А что если взять языки которые от С++ по скорости кода мало чем отличаются? Мы только выиграем в качестве.
E>Или, скажем, приложение, которое разбирает и перемаршрутизирует трафик с сотнями/тысячами пакетов по каждому соединению. И соединений по несколько десятков. И временами интересные эффекты на уровне сетевого стека начинают происходить (к примеру, соединение умирает, а через select это не видно, как будто сокет жив и здоров). И опять, из простой по логике задача превращается в сложную по исполнению из-за своих условий.
Как не странно дрова и сетевые протоколы в Сингулярити написаны на C# и не уступают в эффктивности Линуксу с Виндовс. Хотя надо признать, что задача битодробления действительно хорошо подходя для С++ и единственной его проблемой тут будет его небезопасность.
E>Так что есть еще место для объектно-ориентированного почти ассемблера с шаблонами и исключениями (но без замыканий, монад, примитивов синхронизации и прочего).
Не так. С граблями, UB, скудными библоитеками, и без... далее по тексту.
E>Вообще-то на моей памяти максимальные оценки здесь получали как раз внезапно появляющиеся адепты функционального программирования, которые начинали рассказывать разные необычные для mainstream-программистов вещи.
Ну, ты то к ним не относишся и в топе форума.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Речь идет именно о морде. E>Существующая морда написана в лоб и слишком прожорлива. Сейчас приходится многое переделывать, чтобы удовлетворить поставленным условиям.
Блин, GUI то с каких пор является коньком С++? На нем GUI всегда было гемороем если не вспоминать C++Builder.
Я тебе на C# напишу такое ГУИ в десятки раз быстрее, проще и надежнее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Хм, т.е. все улучшения которые дают Немерл и Окамл это уменьшение многословности? Мда уж что-то тогда индустрия на месте топчется получается, только шаги красивше и меньше выходят.
Это ЗНАЧИТЕЛЬНОЕ увеличение уровня языка, при спопоставимой с С++ производительностью.
Давай простой эксперемент проведем.
К сожалени, человек практически не может оценить более мощьный язык. Об этом замечательно в свое время сказал Пол Грэхем
Вот попробуй сравнить классический ОО-код (на C#, правда, но на C++ он меньше не стал бы) на ООЯ с кодом на Немреле написанном в фукнциональном стиле: Re[9]: Принцип подстановки Барбары Лисков
Можно попробовать сравнить и на простых примерах. Покажи, например, как ты на С++ решил бы задачу преобразования массива целых (скажем std::vector<int>) в строку где каждое значение разделено запятой.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, dr.Chaos, Вы писали:
DC>>>Переносимость на уровне исходников, это и есть основной приоритет комитета.
VD>>К сожалению они добились полностью протевоположенного результата. DC>Какого? Переносимости на уровне исходников нет? .
Ага. Странно что ты считашь себя С++-программистом и не знал этого. Полной переносимости нет, так как компиляторы не реализуют стандарт, и так как стандарт изобилует кучей мест где возможно UB. Про то что такое UB объяснять надо?
DC> Ты открыл мне глаза. Только как я компилюсь каждый деть с одним кодом под Win/AIX, может я что-то неправильно делаю??
Ты используешь не весь С++, а его упрощенный сабсэт который переносим для выбранных тобой компиляторов. Причем ты находишь этот сабсэт по интуции тупо компилируя и тестирую код на обоих платформах. Так же ты избегаешь использования чужих библиотек, так как не хочешь разбираться в том, что они используют из "запрешенного С++".
DC>Влад удобнее хотя бы потому, как это проверенный временем инструмент. Те что по-новее пока в стадии, если не разработки, то активного тестирования — не дальше.
С тоже был проверен временем, а С++ молод и недоработан. Но почему-то ты на С сейчас не пишешь ведь.
VD>>С++ марально устарел еще 5, а то и больше лет назад. Это здравый логический вывод. DC>В чем его моральная старость?
Во многом. Главный список фич:
1. Наличие моря UB.
2. Отсуствие автоматического управления памятью.
3. Не типобезопастность.
4. Наличие моря граблей в добавок к гланым гряблям из п. 3.
5. Плохая выразительность определяемая отсуствием в языке (вделенно так как библиотечная реализация перечисляемых фич сильно ущербна) удобных конструкций вроде функциональных объектов, интерфейсов (или классов типов Хаскеля если угодно), замыканий, модульности, метааднных, компонентности, сопоставления с образцом, полноценной системы метапрограммирования.
DC>Каких именно слов? То, что это достаточно хороший инструме
Например, вот этих:
Кто кроме С++ дает такие возможности с обобщенным программированием при строгой типизации? Java, .Net?
Чем тебе дженерики дотнета не обобщенное программирование при строгой типизации? И знаком ли ты с обобщенным программированием в Хаскеле и ОКамле, например?
DC>Влад кто из производителей движков/ОС/драйверов переходит на Немерле/ОКамл/...
Самые умные.
VD>>Второе покоеление уже писалось с использованием скриптов и С++. DC>Использование скриптов ИМХО еще позже появилось.
Погляди Анрэл 1.
VD>>Следующие должны писаться уже без С++, да и без скриптов. Технологии резко двинулись вперед и мы имеем все что имели и в скриптах, и в С++ (причем без их проблем) в одном флаконе.
DC>Кому должны и где имеем?
По логике должны. Но логика не всегда работает в человеческом мире.
DC> Где 3Д библиотеки для Немерле/ОКамл/... которые удовлетворяют разработчиков движков?
Они прекрасно исползуют имеющиеся бибилотеки. Для Немерле будет радным XNA, от МС и DirectX (хотя с выходом XNA смысла в последнем мало), для ОКамла лучше одойдет OpenGL, так как он довольно кросплатформынй. В прочем и для Немерла можно OpenGL исползовать. Инетроп у него отличный. Любые С-шные библотеки в виде dll/so он глотает без проблем.
DC>Какие поименно? — причем в разрезе применения для ОС/драйверов/графических движков.
Выразительность, типобезопасность, безграбельность, проверяемость (контрль времени компиляции за инвариантами и т.п.), ктаткость. В общем, почитай о том же Немерле или Скале хотя бы. А лучше попробуй. Уверяю тебя, что как только втянешся мнение твое резко начнет меняться. Я вообще-то тоже старый С++-ник. Просто меня перевербовали. Сначала через компонентные технологии, а потом и по астальным каналам.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Каких возможностей не хватает в С++ : сопоставления с образцом? — В движках всегда switch'a хватало;
Про блаба я уже давал ссылку?
DC> Замыканий? — да могу я их сделать функторами; как собственно и ФВП ; да это не будет так красиво, и кратко как в ОКамле или Немерле.
Это будет настолько не красиво, что ты быстро бросишь это дело и вернешся к циклам и т.п. Да и читать это бует не очень приятно. Без сахара вроде лямбд и частичного применения ФВП мало что дают. Хотя бесспорно их можно и в С++ использовать. Но не красиво это получается.
DC>Только объясни мне где в алгоритмах в движке их применять. Я, если честно, не вижу сильного выигрыша от их применения.
Я не знаком с твоей спецификой, но уверяю тебя, что в любом коде будет выигрышь.
VD>>Просто позволят решать более сложные задачи, или решать те же задачи меньшими силами.
DC>Вот блин опять абстракция, я про движок графический спрашиваю. То что в физическом движке ФП будет возможно лучше использовать, я соглашусь, но ты мне объясни где я выиграю в 3D движке???
Ладно. Уломал речистый. Дам тебе один убийственный аргумент — макросы. Они тебе позволят сделать движок в разы проще и максимально эффективно. Более мощьного средства для создания системных средств еще не придумано. А макросы того же Немерла — это одна из лучих реализаций оных среди существющих. Соперчинчать реально могут только макросы Лиспа, но Лисп динамически типизирован, весма своеобразен и слишком сложен для восприятия (скрипты им вряд ли заменишь). А уж метапрограммирование на шаблонах С++ вообще пролетает по всем статьям.
ЗЫ
Эти слова не значат, что кроме макросов ничего нет. Просто приемущество макросов тебе будет проще понять. А там если заинтересушся, то все пойдет смо собой.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Читай выделенное.для рендеринга просто используется как ты правильно заметил дополнительный специализированный процессор.
Ага. И, заметь, все вычисления он производит самостоятельно. Тебе только надо ему данные (в виде текстур, полигонов и шейдеров) скормить. А это отнюдь не самые бльшие процессоные ресурсы требует.
Такие языки как C# или Nemerle с такой задачей справятся великолпно. Да что там они. Вот погляди: http://www.haskell.org/haskellwiki/Frag
это Ку3 написанный на Хаскеле! А Хаскель — это очень медленно.
DC>MC там представлен я не сомневаюсь, только MC не производитель движков.
Да? А кто по твоему MS Flight Simulator делает?
А Эдж Оф Эмпаир под чьим крылом? К тому же они делают главную штуковину DirectX, XNA и драверы для видео. Так что они точно знают что нужно разработчикам игр.
VD>>Я сказал, что с точки зрения этой презентации (а стло быть всей разработки игр класса Анрыла) новый стандарт практически ничего не даст. Причем то что помогло бы разработчиком игр было бы одновременно полезным и для большинства других пользователей языка. Но это не путь С++, по всей видимости.
DC>Оооо. Сколько оговорок появилось для простой фразы — Ничего не изменит.
Какие оговорки?
VD>>Любую задачу потенциально можно решить на ассемблере или скажем на С. Но это: VD>>1. Не разумно в большинстве случаев. VD>>2. Требует больеш ресурсов и усилий чем может реально быть в распоряжении компании.
DC>С и Асм не предоставляют столько высокоуровневых абстракций для проектирования. Мало того на С++ действительно неразумно решать многие задачи, т.к. появились специализированные инструменты.
Все тоже самое справидливо по отношению скажем С++ vs. Немерле. Написать то можно все, но абстракций удобных меньше. Тало быть писать сложнее. А это приводит к тому, что при некотором уровне сложности задачи перестают решаться в разумные сроки и за разумные деньги.
DC>Я и не сомневаюсь, только до этого, как ты сам оценил 5-10 лет.
Через 10 будет поздно. Все уже будут там.
DC>С++-шники не у дел не останутся . Они просто перейдут в другие области.
С-шники и даже Кобольники тоже так говорили. И некоторые до сих пор работают на своих любимых языках.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
New For PC: Symantec's Zortech 3.1 Compilers For OS/2, DOS 12/16/92 CUPERTINO, CALIFORNIA, U.S.A., 1992 DEC 16 (NB) -- Hoping to increase the popularity of its Zortech C-plus-plus compiler, Symantec has introduced two new versions for the DOS and OS/2 platforms.
The new versions, Zortech C-plus-plus version 3.1 for DOS and Windows 3.1 and Zortech C-plus-plus version 3.1 for OS/2 2.0, are fully compliant with AT&T CFRONT C-plus-plus version 3.0 and ANSI C and, according to the company, offer full 32-bit and advanced numerics support.
The company says that AT&T compliance is important to programmers because it gives support for pre-compiled headers and templates, thereby saving compilation time and increasing code reusability. Zortech C-plus-plus 3.1 conforms to the IEEE-754 floating point standards and the NCEG 91-015 draft for numerical extensions.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Тема, я думаю исчерпана.
Ой, очень давно. И вообще я уже несколько часов читаю и с ужасом жду когда вы начнете обсуждать очередность выхода компиляторов С от МС, а потом Фортрана от IBM и понимаю, что спать мне оставалось каких-то два часа... (с)
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
C>>Некоторые товарищи до сих пор preprocessor-based компиляторы поставляют.
IT>
А что смешного то? Прикинь С++ переносим только с бутылкой водки и какой-то матерью, а С переносим замечательно. Но мы такие вот умные и написали все на С++. Что делать если надо это дело по шустрому портировать на 20 платформ? И тут мы находим препроцессор в С... быстренько делаем код совместимым с ним и тупо компилируем исходники на все нужных платформах.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>я тоже могу привести свой код, но смысл? я специально привёл маленькие примеры, которые позволяют увидеть экспрессивную мощь ФП. для любой обработки данных (с которой я встречался) ф.п. упрощает дело. и чем сложнее алгоритмы, тем больше ты выигрываешь. НО — это работает медленней, чем императивнй код
Последнее заблуждение. Или не всегда правда. Если испльзовать Хаскель, то конечно. Если пытаться реализовать все функционально (даже, скажем быструю сортировку), то тоже конечно. Но если использовать язык который позволяет писать и функционально и объектоно-ориентировано, и еще макросами побаловаться, то все уже совсем выглядит по другому. Можно добиваться скорости С++ или даже больше (за счет более сложных алгоритмов) и при этом иметь краткий и выразительный код.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, dr.Chaos, Вы писали: DC>>Ну уж нет, Си явно выражал концепцию структурного программирования, т.е. вводил новые абстракции что ли. S>С++ компактнее С. Новые абстракции не нужны сами по себе — они оправданы только тем, что сокращают запись.
С++ компактнее С только при условии, что на С код пишется в объектно-ориентированном стиле. ООП позволяет решать более сложные задачи за счет ОО-декомпозиции. Но кода получается обычно даже больше.
Но на С можно писать и в фукнциональном стиле, и в простом структрном, процедурном. При этом иногда даже получается более краткий и понятный код.
Вот такие парадоксы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Простота == лаконичности.
Это не верно. Отличные примеры демонструющие ошибочность такой логики это:
* J.
* Регулярные выражения.
Они локаничны, но совершенно не понятны.
Правильно будет утверждать, что простота == выразительная лаконичность.
То есть когда мы можем выразить мысль более кратко, но при этом не теряя в понятности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>В предыдущем посте я имел в виду сложность модели. А в начальном именно упрощение синтаксиса. Т.е. Понятия ООП позволили представлять более сложные модели. Немерле и ОКамл, по вашим, утверждениям служат только для уменьшения многословности, что я воспринял, как простое упрощения синтаксиса (не хочу употреблять "синтаксический сахар", а то еще один флейм поднимут ). Я прошу дать именно те абстракции которых нет в С++, но есть в Немерле/ОКамл, которые позволят мне понизить сложность при создании алгоритмов для 3Д движка.
Дык модели они тоже более кратко описывают. И более того, они позволяют эти модели так же кракто оанализировать! И тут С++ сливает по полной. Впрочем как любой чистый ООЯ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eugene0, Вы писали:
E>Между тем, есть отличные игры, которые без нее неплохо обходятся. Посмотрите, например, на Call of Duty.
Дык посмотри дуум 1-2 или вообще Вульфа2Д. Они прекрасно обходились без 3Д-акселерации (да и без 2Д тоже).
Хреновый аргумент? Вот твой такой же.
Да, сегодняшние игры обходятся, но они примитивны. Вних мало объектов, мало динамики, мало взаимодействий. Будущие игры возможно позолят иметь 64К юнитов, но уже не таких примитивных тупых точке как в Казаках, а таких как боты в Ку3. Но при этом ЦП (и не один!) должен будет целиком заняться логикой их поведения используя для этого мощьные средства вроде сопоставления с образцом или локики предикатов. Вот тогда перекладывание всей физики на плечи специализированной железки будет оправдано и даст хороший эффект.
Только проблема в том, что тут нужны стандарты и интеграция. Такие ускорители лучше всего встраивать в графические платы. Все равно игровая машина без серьезного видо-адаптера немыслема.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Наоборот, это сейчас самая горячая тема. Чисто в графике уже практически достигли фотореализма, дальше только трассировка лучей.
Ладно тебе. Там еще копать и копать до фотореалистичности. Рендеринг времен Парка юрского периода и то круче был.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>А призываю к тому, чтобы в C++ камнями перестали кидаться от нечего делать.
Если внимательно приглядеться, то можно понять, что от нечего делать камнями никто не кидается. Сторонники C++ заявляют что-то вроде: "Я C++ уже n лет использую, он зарекомендовал себя как хороший инструмент для решения задач и я его буду продолжать юзать". Люди отвечают: "Несомненно, C++ — не идеальный язык (как и любой ЯП). Так что наверняка сейчас уже появились ЯП мощнее C++, лучше подходящие для многих задач. Если же таких языков по-твоему не появилось, так почему же ты мучаешься с граблями C++? Если ты вынужден писать на C++, тогда не говори, что он лучий. Если у тебя есть выбор (но ты не видишь достойного преемника C++) то ты можешь поспособствовать тому, чтобы он появился". Последнее предложение — не обобщение. Но и эту идею можно заментить в той или иной форме, почитав сообщения.
Если кто-то и кидается камнями в C++ от нечего делать (я, например ), то это случается весьма редко. Чаще люди проводят обычную конструктивную критику чьего-то порой нездорового консерватизма.
Здравствуйте, VladD2, Вы писали:
VD>Так к системным задачам традиционно относят компиляторы, но любой кто более менее знает Лисп, Хаскель, ОКамл... Немерле в конце концом понимает, что писать компиляторы на С++ весьма не разумное решение.
К системным задачам относят не только компиляторы и драйверы.
E>>Вот к примеру, требуется GUI программка для on-line мониторинга сотни-полутора параметров с дальнейшим привязыванием к этому мониторингу трендов, звуковой сигнализации и пр. И чтобы для каждого параметра можно было задавать свои правила обработки. И чтобы работая в фоне отжирала не более 10%-15% процентов процессорного времени. И памяти не больше десятка-другого мегабайт. Бах -- и задача из простой превращается в сложную.
VD>Забыл добавить "... на С++". Иначе это не так верно. Замечательный пример обратного я скачал буквально недвано. BitTorrent. Программа написана на Питоне и офигительно качает себе в бэкграуде тонны файлов. Ну, да, жрет она 40 метров на моей машине. Ну, и фиг с ними! За-то она не вылетает, не глючит, проста и удобна в использовании, ставится в одно касание.
Нифига это не одно и тоже. BitTorrent-у не нужно реагировать на случайным образом возникающие события он просто занимается перекачкой данных.
VD>Как не странно дрова и сетевые протоколы в Сингулярити написаны на C# и не уступают в эффктивности Линуксу с Виндовс.
Где не уступают? Где есть хотя бы одна промышленно используемая система на Сингулярити, работающая в режиме 24x7?
E>>Вообще-то на моей памяти максимальные оценки здесь получали как раз внезапно появляющиеся адепты функционального программирования, которые начинали рассказывать разные необычные для mainstream-программистов вещи.
VD>Ну, ты то к ним не относишся и в топе форума.
Из любого правила есть исключения. Ты, кстати, не далеко от меня обосновался, так что ктобы жаловался
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, konsoletyper, Вы писали:
E>>А призываю к тому, чтобы в C++ камнями перестали кидаться от нечего делать.
K>Если внимательно приглядеться, то можно понять, что от нечего делать камнями никто не кидается.
У меня другое впечатление.
K>Сторонники C++ заявляют что-то вроде: "Я C++ уже n лет использую, он зарекомендовал себя как хороший инструмент для решения задач и я его буду продолжать юзать". Люди отвечают: "Несомненно, C++ — не идеальный язык (как и любой ЯП). Так что наверняка сейчас уже появились ЯП мощнее C++, лучше подходящие для многих задач. Если же таких языков по-твоему не появилось, так почему же ты мучаешься с граблями C++?
А если не мучаешься и никогда не мучался?
Я могу, в принципе, поверить, что кто-то ужасно страдает от программирования на C++. Но вот не мой это случай
K>Если у тебя есть выбор (но ты не видишь достойного преемника C++) то ты можешь поспособствовать тому, чтобы он появился".
Языкостроение -- это не моя епархия. Так что я лучше не буду лезть туда, где от меня нет толку.
K>Если кто-то и кидается камнями в C++ от нечего делать (я, например ), то это случается весьма редко. Чаще люди проводят обычную конструктивную критику чьего-то порой нездорового консерватизма.
У меня другое впечатление -- люди обвиняют разработчиков в каких-то грехах, не желая понимать многих других вещей. Например, исторического контекста, на котором разворачивались события. Важности унаследованного кода. Наличия конкурирующих поставщиков коммерческих версий C++ компиляторов, которые заинтересованны в привязывании клиентов исключительно к своему продукту. И т.д. и т.п.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
E>>Существующая морда написана в лоб и слишком прожорлива. Сейчас приходится многое переделывать, чтобы удовлетворить поставленным условиям.
VD>Блин, GUI то с каких пор является коньком С++? На нем GUI всегда было гемороем если не вспоминать C++Builder.
Если ты видел только MFC, ATL и C++Builder, то это не значит, что GUI всегда было геморроем.
VD>Я тебе на C# напишу такое ГУИ в десятки раз быстрее, проще и надежнее.
Во-первых, сложность не в GUI.
Во-вторых, написанный тобой GUI я имел возможность наблюдать, пользуясь некоторое время назад Янусов. В сад такое быстрое, простое и надежное GUI на C#.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Alexmoon, Вы писали:
IT>Думаю, что для уровня ядра в качестве переносимого высокоуровнего ассемблера лучше подойдёт C, а не C++.
Как вы любите цеплятся за определения. Ответьте себе сами. C# еще менее подходит для этого.
IT>С одной оговоркой. Метопрограммирование на шаблонах — это тупиковая ветвь развития человечества.
Сильное определение. Уверенность в себе — это конечно похвально. Но я бы как минимум заменил артикль это на возможно.
Дальнейший спор не имеет смысла, поскольку он не этого уровня обсуждения. Скажу единственное. Все нужно рассматривать в концепциях языка. И на столь громкий выпад, отвечу. Нет. Объяснения не имеют смысла, поскольку это будет обречено на двести постов флейма. Все и так уже описано не раз. Достаточно для себя сделать вывод
A>В языке достаточно минимально необходимых примитивов для эмуляции чего угодно. Все что нельзя сделать, неправильно концептуально спроектировано
IT>Мне очень нравится декларативная составляющая современных языков. Не мог бы ты сэмулировать на C++ атрибуты?
Мог бы и это не сверхестественное умение. Просто в концепциях языка с точки зрения логики сие выглядело бы совершенно по другому, но если кому так не нравится, или кто то боится ошибится при реализации, тогда смотри выше мое предыдущее сообщение. Два раза одно и то же я не повторяю. Мы не дети. Давайте без нравится, а то я напишу что мне нравится Jennifer Lopes.
IT>Ничего логичного и естетсвенного. Метапрограммирование на шаблонах — это высокоинтеллектуальное извращение. А извращение не может быть естественным. Даже высокоинтеллектуальное.
Ничего общего с тем что вы определили не имеет. То что в вашем понимании извращение, может таковым совершенно не являтся, но в концепциях С# конечно такой гибкости нет, поэтому можно и таким аттрибутом по умолчанию наградить. Давайте озаглавливать контексты "Я так думаю", и наче обсуждение обречено.
Здравствуйте, IT, Вы писали:
IT>Для меня тема C++ исчерпана давно. Если бы некоторые индивидуумы всерьёз не считали бы C++ "сложным языком для сложных программ" и не пудрили периодически здесь мозги другим, то я бы о нём уже давно забыл.
Я в любом случае приношу свои извинения, раз человека так допекло. Но попрошу. Давайте остановимся на фразе:
Бывает. Видимо я (мы) слишком чувствительны и восприимчивы к тому, что на нас как на пользователей так долго и так нагло кладёт комитет. У нас со временем это стало обоюдным. Ну а вас это не волнует совершенно. Понимаю.
Вы не являетесь четким определением параметров страшного сна. Забыли и слава богу, для нас. Те индивидуумы, которыми вы соблаговолили назвать и меня до сих пор чудесно справляются с поставленными задачами и с не меньшей эффективностью нежели вы господин. Я уже сам нервничать начинаю от столь громких заявлений. Все за прохрадительными напитками То что проектирование на ++ требует большего skills — это не значит что это извращение по сравнению с #. Я уже говорил. Каждому свое. Нет не решаемых архитектурных проблем ни с применением ни одного ни другого. То что вы считаете "так нагло кладет комитет" может быть лишь просто суровой действительностью и если бы он нагло клал, то вы бы и в сторону шаблонов развития никогда бы не увидели.
А теперь дружно порвали рубахи и обменялись аплодисментами
Здравствуйте, VladD2, Вы писали:
VD>Они локаничны, но совершенно не понятны.
Лаконичность нужно мерить не в символах, а в синтаксических элементах. Иначе мы получим рассуждения С.Г. о "синтаксическом оверхеде", а замена всех имен переменных на одно-двух-символьные сочетания должна будет существенно упрощать программу.
поэтому, например, в эмуляция ООП в C менее понятна, чем настоящее ООП в С++:
Здравствуйте, VladD2, Вы писали:
VD>С++ компактнее С только при условии, что на С код пишется в объектно-ориентированном стиле. ООП позволяет решать более сложные задачи за счет ОО-декомпозиции. Но кода получается обычно даже больше.
Нет. Шаблонные функции тоже рулят, т.к. позволяют не писать отдельные версии на каждый тип. Кстати, K&R C, руливший во времена С++, все еще не позволял указывать типы аргументов в объявлениях функции и требовал объявлять все переменные только в начале. Насколько я помню, возврат структур также был запрещен (могу ошибаться). Ссылок в С тоже не было.
VD>Но на С можно писать и в фукнциональном стиле, и в простом структрном, процедурном. При этом иногда даже получается более краткий и понятный код. Короче, чем на С++ уже не получится, т.к. такая программа автоматически будет и С++ программой. Более того, структурно-процедурная программа на С++ будет скорее всего компактнее, чем на С, благодаря всяким простым штукам навроде наследования структур, которого не было в С.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Alexmoon, Вы писали: A>Дальнейший спор не имеет смысла, поскольку он не этого уровня обсуждения. Скажу единственное. Все нужно рассматривать в концепциях языка.
Вот как раз не надо рассматривать ничего в концепциях языка. Потому как бессмысленно пытаться рассматривать "лыжи" на языке, где нет понятия "снег". A>Мог бы и это не сверхестественное умение. Просто в концепциях языка с точки зрения логики сие выглядело бы совершенно по другому, но если кому так не нравится, или кто то боится ошибится при реализации, тогда смотри выше мое предыдущее сообщение.
Дело не в Дженнифер Лопес, а в совершенно объективных и измеримых характеристиках. Почему-то когда сравнивается эмуляция ООП на С с его реализацией в С++, ты с готовностью признаешь, что С++ — far superior, т.к. в нем не нужно вручную заполнять VMT, что снижает шанс сделать дурацкую ошибку и сокращает код. Зато эмуляция атрибутов кошмарными конструкциями — это вполне нормально, потому как "в концепциях языка с точки зрения логики это то же самое".
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
DC>> Замыканий? — да могу я их сделать функторами; как собственно и ФВП ; да это не будет так красиво, и кратко как в ОКамле или Немерле.
VD>Это будет настолько не красиво, что ты быстро бросишь это дело и вернешся к циклам и т.п. Да и читать это бует не очень приятно. Без сахара вроде лямбд и частичного применения ФВП мало что дают. Хотя бесспорно их можно и в С++ использовать. Но не красиво это получается.
Там где это будет эффективней я могу и потерпеть синтаксический оверхэд.
DC>>Только объясни мне где в алгоритмах в движке их применять. Я, если честно, не вижу сильного выигрыша от их применения.
VD>Я не знаком с твоей спецификой, но уверяю тебя, что в любом коде будет выигрышь.
Вот только в чем? В красоте или в эффективности выполнения? BulatZiganshin утверждает что на хаскеле будет медленнее, хотя и более кратко и красиво.
VD>>>Просто позволят решать более сложные задачи, или решать те же задачи меньшими силами.
DC>>Вот блин опять абстракция, я про движок графический спрашиваю. То что в физическом движке ФП будет возможно лучше использовать, я соглашусь, но ты мне объясни где я выиграю в 3D движке???
VD>Ладно. Уломал речистый. Дам тебе один убийственный аргумент — макросы. Они тебе позволят сделать движок в разы проще и максимально эффективно. Более мощьного средства для создания системных средств еще не придумано. А макросы того же Немерла — это одна из лучих реализаций оных среди существющих. Соперчинчать реально могут только макросы Лиспа, но Лисп динамически типизирован, весма своеобразен и слишком сложен для восприятия (скрипты им вряд ли заменишь). А уж метапрограммирование на шаблонах С++ вообще пролетает по всем статьям.
Ммм. Возможно, мне трудно оценить их мощь. Но с алгоритмами они врядли способны что-то сделать, разве что упростят построение модели.
VD>ЗЫ
VD>Эти слова не значат, что кроме макросов ничего нет. Просто приемущество макросов тебе будет проще понять. А там если заинтересушся, то все пойдет смо собой.
Насколько я понимаю эти макросы и есть основной конек Немерле.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>А призываю к тому, чтобы в C++ камнями перестали кидаться от нечего делать.
K>Если внимательно приглядеться, то можно понять, что от нечего делать камнями никто не кидается. Сторонники C++ заявляют что-то вроде: "Я C++ уже n лет использую, он зарекомендовал себя как хороший инструмент для решения задач и я его буду продолжать юзать". Люди отвечают: "Несомненно, C++ — не идеальный язык (как и любой ЯП). Так что наверняка сейчас уже появились ЯП мощнее C++, лучше подходящие для многих задач. Если же таких языков по-твоему не появилось, так
почему же ты мучаешься с граблями C++? Если ты вынужден писать на C++, тогда не говори, что он лучий.
Ты найди пожалуйста хоть одну фразу, где я или eao197 назвали С++ лучшим. И приведи тут, а не просто воздух сотрясай. С граблями С++ я не мучаюсь, просто обхожу .
K>Если у тебя есть выбор (но ты не видишь достойного преемника C++) то ты можешь поспособствовать тому, чтобы он появился". Последнее предложение — не обобщение. Но и эту идею можно заментить в той или иной форме, почитав сообщения.
А что ты считаешь достойным приемником? В каком смысле достойным?
K>Если кто-то и кидается камнями в C++ от нечего делать (я, например ), то это случается весьма редко. Чаще люди проводят обычную конструктивную критику чьего-то порой нездорового консерватизма.
А в чем наш консерватизм? У нас есть любимый инструмент, зачем этот инструмент поносить? Мало того если ты им не пользуешься? Мы вроде не поносили С#, Немерле и сотоварищей? Смысл ругать отвертку за то что она такая? Просто с распространенностью и универсальностью С++ пока еще никто не сравнялся. О причинах можно много говорить, но факт остается фактом.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, Sinclair, Вы писали:
S>Вот как раз не надо рассматривать ничего в концепциях языка. Потому как бессмысленно пытаться рассматривать "лыжи" на языке, где нет понятия "снег".
Все нужно рассматривать в концепции языка. Понятие "снег" не является generic. Ни один язык не вместит всех понятий на уровне встроенных типов. Для меня необходимым и достаточным является то, что с максимальной гибкостью я могу определить любое из высокоуровневых понятий набором базовых. То что понятие гибкость и локаничность взаимозависимы, ну так здесь никто и никогда не найдет золотой середины. Одни средства появляются не на смену другим а лишь в их дополнение. И то что используются до некоторых пор языки, которые кто то считает не уместными — это не их недостаток и лишь характеристика, что они все еще актуальны и нет до сих пор понятий, которые за конечное время и с доступным владением интрумента невозможно выразить. Нет ничего абсолютного, есть только достаточное. Поэтому каждому свое. Шарп создавали для прикладников с реализацией устоявшихся понятий, для увеличения скорости и простоты разработки и некоторой степенью защиты от кривых рук, ну и слава богу, и это не обозначает что все это нужно пихать в ++. Я уже сказал зачем. Он развивается в те стороны, которые для него актуальны и логичны. Сказанное касается и для всех остальных инструментов и языков и всего.
Для тех на кого клал комитет по их мнению, да простят меня за злословие, создают свой комитет по защите обманутых потребителей и т.д.
Прошу не отвечать на данное высказывание. Этот лишь аттрибут поддержки интереса к абстрактной сложности вопроса.
A>>Мог бы и это не сверхестественное умение. Просто в концепциях языка с точки зрения логики сие выглядело бы совершенно по другому, но если кому так не нравится, или кто то боится ошибится при реализации, тогда смотри выше мое предыдущее сообщение. S>Дело не в Дженнифер Лопес, а в совершенно объективных и измеримых характеристиках. Почему-то когда сравнивается эмуляция ООП на С с его реализацией в С++, ты с готовностью признаешь, что С++ — far superior, т.к. в нем не нужно вручную заполнять VMT, что снижает шанс сделать дурацкую ошибку и сокращает код. Зато эмуляция атрибутов кошмарными конструкциями — это вполне нормально, потому как "в концепциях языка с точки зрения логики это то же самое".
Кошмарными для кого? !!!!!!!!!!!!!!!!!!!!!!!!!!! Ну читайте же вы между строк и то что инструмент обладает необходимым набором составляющих поезда — это абсолютно не обозначает что он должен включать и его определение и также не значит что его нужно складывать из понятия колбаса (что вы определяете как кошмар).
Я работаю плечом к плечу с определенным количеством коллег, которые и на эти недостатки плевать хотели ради тех локальных удобств, которые есть в C. И слава богу. Это лишь их средство реализации. Главное чтобы у нас были доступные нам механизмы сопряжения. Главное чтобы их механизм разработки удовлетворял окружающим их условиям и не более и не менее. И думающий человек всегда найдет выход из сложившейся ситации, заметьте не эмоциональный.
NO EMOTION ONLY MIND
Это все было о девочках. А теперь конкретный вопрос, на который ни вы не я и никто не ответит.
Sinclair notes:
Дело не в Дженнифер Лопес, а в совершенно объективных и измеримых характеристиках.
Что есть ИЗМЕРИМЫЕ а тем более ОБЪЕКТИВНЫЕ характеристики?
Продолжая сопоставлять и анализировать все вышесказанное, попытайтесь ответить так, чтобы не положить ни на единого хотя бы участника общения. Не говоря уже о высоком. А то мы так любим примерять к себе то, что никакого отношения к нам не имеет.
Здравствуйте, VladD2, Вы писали:
E>>Между тем, есть отличные игры, которые без нее неплохо обходятся. Посмотрите, например, на Call of Duty.
VD>Дык посмотри дуум 1-2 или вообще Вульфа2Д. Они прекрасно обходились без 3Д-акселерации (да и без 2Д тоже). VD>Хреновый аргумент? Вот твой такой же.
Этим играм сто лет в обед, а Call of Duty 2 вышел в прошлом году, когда производители уже успели вволю наиграться с физическими движками. Так что это твой аргумент так себе.
Давайте все-таки выясним, чем конкретно реалистичная физика может сделать интереснее игру.
VD>Да, сегодняшние игры обходятся, но они примитивны. Вних мало объектов, мало динамики, мало взаимодействий. Будущие игры возможно позолят иметь 64К юнитов, но уже не таких примитивных тупых точке как в Казаках, а таких как боты в Ку3. Но при этом ЦП (и не один!) должен будет целиком заняться логикой их поведения используя для этого мощьные средства вроде сопоставления с образцом или локики предикатов. Вот тогда перекладывание всей физики на плечи специализированной железки будет оправдано и даст хороший эффект.
По моему опыту, сложность AI ограничивается вовсе не производительностью процессора. У нас AI не тормозит. Что угодно тормозит, рендер, анимация, та же физика, а вот AI нет.
IMHO проблема тут не в производтельности, а в сложности реализации сложных моделей поведения, а также, в некторых случаях, в целесообразности этого.
Сложность AI не означает интересности игры. Во многих 3D-шутерах сложную логику поведения врагов просто никто не оценит. Q3 изначально был нацелен на multiplayer, боты там, по-моему, вообще больше для тестов и начальной тренировки новичков. Ну если ты все же играешь в Q3 один, какого усложненное поведение ты хотел бы у них увидеть?
Здравствуйте, Alexmoon, Вы писали: A>Все нужно рассматривать в концепции языка. Понятие "снег" не является generic.
Кто это сказал? Снег, значит, есть, а понятия нету?
A>Ни один язык не вместит всех понятий на уровне встроенных типов.
Ну, если рассуждать обо всем с позиции типов — да. Но язык не обязан сводиться к типам. Да и само понятие "тип" сильно зависит от языка. В ассемблере, например, "тип" == количество байт, и указатель неотличим от инта.
A>Для меня необходимым и достаточным является то, что с максимальной гибкостью я могу определить любое из высокоуровневых понятий набором базовых.
Это иллюзия. Если тебя оставить наедине с по-настоящему базовыми понятиями, ты через полчаса запросишься обратно к маме. А ну-ка сконструируй мне хотя бы конвертер Koi-8->Win1251, пользуясь _исключительно_ нулем, инкрементом, и функцией выбора N-го аргумента!
Так что вопрос ровно в том, какие понятия считать базовыми. Вот С считает, что структур вполне достаточно для всех случаев жизни и можно вполне успешно определить "класс" как структуру, а объект — как другую структуру.
A>То что понятие гибкость и локаничность взаимозависимы, ну так здесь никто и никогда не найдет золотой середины.
Вот это утверждение хотелось бы как-то обосновать. Кто гибче — С или С++? А ведь С++ лаконичнее!
A>Одни средства появляются не на смену другим а лишь в их дополнение. И то что используются до некоторых пор языки, которые кто то считает не уместными — это не их недостаток и лишь характеристика, что они все еще актуальны и нет до сих пор понятий, которые за конечное время и с доступным владением интрумента невозможно выразить.
Ага. Это т.н. "классическая квантовая механика". Предполагает, что можно измерить любой параметр с любой точностью. К сожалению, на высокоэнергетических проектах проявляются релятивистские эффекты: нельзя измерить координату с бесконечной точностю, т.к. это потребует бесконечной неопределенности импульса. А она запрещена, p < mc.
Вот и в программировании так же: некоторые вещи в принципе невозможно реализовать на более простой технологии, т.к. человеко-годы стремятся к бесконечности. Возникает потребность в более производительных инструментах. Парадокс, знаете ли, ахилла и черепахи.
A>Нет ничего абсолютного, есть только достаточное. Поэтому каждому свое. Шарп создавали для прикладников с реализацией устоявшихся понятий, для увеличения скорости и простоты разработки и некоторой степенью защиты от кривых рук, ну и слава богу, и это не обозначает что все это нужно пихать в ++.
Никто и не предлагает всё это пихать в С++. Просто есть некоторые запросы, на которые С++ отказывается отвечать. Не надо копировать ответы из шарпа; можно было бы копировать и другие ответы. Увы.
A>
Sinclair notes:
A>Дело не в Дженнифер Лопес, а в совершенно объективных и измеримых характеристиках.
A>Что есть ИЗМЕРИМЫЕ а тем более ОБЪЕКТИВНЫЕ характеристики?
1. Компактность кода
2. Количество проверок, выполняемых компилятором A>Продолжая сопоставлять и анализировать все вышесказанное, попытайтесь ответить так, чтобы не положить ни на единого хотя бы участника общения.
Запросто. См. выше.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>>Вот как раз не надо рассматривать ничего в концепциях языка. Потому как бессмысленно пытаться рассматривать "лыжи" на языке, где нет понятия "снег".
A>Все нужно рассматривать в концепции языка.
полпробуйте это рассматривать в концепциях машины Тьюринга, к примеру. используя её, легко доказать, что классы не нужны по той простой причине, что типов вообще не существует
A>Что есть ИЗМЕРИМЫЕ а тем более ОБЪЕКТИВНЫЕ характеристики?
бабки приносите, я вам покажу как их измерить
все эти языки появляются для решения всё техз же извечных задач — уменьшения времени программирвования/отладки, увеличения читабельности и надёжности. в Хаскеле большинство ошибок обнаруживается компилятором. в С я периодически наталкиваюсь на нулевые укащатели, или на ручной (и потенциально ошибочный) кастинг указателей туда/сюда. в хаскеле я записываю алгоритм в одлну строчку, в Си — в десять, к тому же разбросанных по программе потому, что нет клозур для sort. я тут привёл 3 примера кода, написанного на хаскел (http://rsdn.ru/Forum/?mid=2337746&flat=0
), и так и не дождался чтобы хоть кто-нибудь написал для сравнения их аналоги на своём языке
чистый результат в моей работе — я написал архзиватор, по возможностям сравнимый я 7zip, но кодом в три раза меньше. подозреваю, что и время разработки было в три раза меньше, хотя это сложнее сравнить
Здравствуйте, eugene0, Вы писали:
E>Давайте все-таки выясним, чем конкретно реалистичная физика может сделать интереснее игру.
Геймплей некоторых игр основан именно на реалистичной физике. Например, автосимуляторы. Есть более редкие и своеобразные экземпляры, например GISH.
Если тебя интересует, чем реалистичная физика может сделать интереснее 3D-шутер, то в качестве игры, где это сделано, могу назвать Half-Life 2.
BZ>>преимущества Хаскела — очень строгая типизация, отлавливающая большинство ошибок с типами, и лёгкость конструирования алгоримтов из составных частей. я не представляю себе потребности игр,
LCR>Тим Свини в своей презентации утверждает, что очень хочется статического контроля выхода за пределы массивов, статического контроля за null-значениями, статического контроля за переполнением, хорошей поддержки concurrency, и подобные мелочей.
скажем так — в других языках этого тоже нет полиморфные строго порверяемые типы имхо есть только в яве 1.5 (насчёт C# не знаю), но по части конструирования сложных типов и их вывода хаскел всё равно очень далёк. и когда ты пишешь какую-нибудь вроде даже не очень сложную конструкцию, у тебя в яве есть только два пути — либо явно выписывать все типы, либо бог с ней, строгой типизацией
вот описание моей библиотеки — http://haskell.org/haskellwiki/Library/Streams . посмотри, какие типы в ней конструируются и это ведь норма для современного программирования, в C++ шаблонах получается не хужее. вопрос только в том, кто будет их выяснять — программист или компилятор
BZ>>вот напоследок ещё один небольшой алгоритм. суть его в том, что есть а-ля RAR список номеров сбойных секторов в архиве и его надо разделить на две части — секторы, чей номер по модулю rec_sectors уникален (их можно восстановить), от тех, которые накладываются друг на друга: LCR>
Здравствуйте, Сергей, Вы писали:
E>>Давайте все-таки выясним, чем конкретно реалистичная физика может сделать интереснее игру.
С>Геймплей некоторых игр основан именно на реалистичной физике. Например, автосимуляторы. Есть более редкие и своеобразные экземпляры, например GISH. С>Если тебя интересует, чем реалистичная физика может сделать интереснее 3D-шутер, то в качестве игры, где это сделано, могу назвать Half-Life 2.
Про HL2 согласен, он весьма завязан на свой физический движок. Местами даже кажется, что дизайнерам чуть ли не прямым текстом сказали: "Ребята! У нас лучшая в мире физика. Будет обидно этим не воспользоваться"
У меня такое ощущение, что я заигрался в адвоката дьявола. А я всего лишь хотел сказать, что физика — не так важна для игры, как, к примеру, красивая графика, и поэтому сравнивать ускоритель физики с 3D-акселератором неправильно. На самом деле я не против физики, нет.
Здравствуйте, eugene0, Вы писали:
E> А я всего лишь хотел сказать, что физика — не так важна для игры, как, к примеру, красивая графика, и поэтому сравнивать ускоритель физики с 3D-акселератором неправильно. На самом деле я не против физики, нет.
Красивая графика — в смысле крутой графический движок с реалистичными эффектами?
Здравствуйте, Сергей, Вы писали:
E>> А я всего лишь хотел сказать, что физика — не так важна для игры, как, к примеру, красивая графика, и поэтому сравнивать ускоритель физики с 3D-акселератором неправильно. На самом деле я не против физики, нет.
С>Красивая графика — в смысле крутой графический движок с реалистичными эффектами?
Да, но не только. Если художники плохие, то они и крутой движок не спасет. Но это, конечно, не имеет отношения к 3d-акселераторам.
Bulat,
BZ>это просто мой спсооб написания ООП-стайл прорграм BZ>a$.b = b a
Оператор "euro" из Understanding monads
BZ>скажем так — в других языках этого тоже нет полиморфные строго порверяемые типы имхо есть только в яве 1.5 (насчёт C# не знаю), но по части конструирования сложных типов и их вывода хаскел всё равно очень далёк. и когда ты пишешь какую-нибудь вроде даже не очень сложную конструкцию, у тебя в яве есть только два пути — либо явно выписывать все типы, либо бог с ней, строгой типизацией
Да, согласен, обычно так и происходит.
BZ>вот описание моей библиотеки — http://haskell.org/haskellwiki/Library/Streams . посмотри, какие типы в ней конструируются и это ведь норма для современного программирования, в C++ шаблонах получается не хужее. вопрос только в том, кто будет их выяснять — программист или компилятор
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Alexmoon, Вы писали: A>>Все нужно рассматривать в концепции языка. Понятие "снег" не является generic. S>Кто это сказал? Снег, значит, есть, а понятия нету?
Нету. Представьте себе. Снег — это то что мы таковым назвали исходя из определенных характеристик свойственных такому состоянию среды.
A>>То что понятие гибкость и локаничность взаимозависимы, ну так здесь никто и никогда не найдет золотой середины. S>Вот это утверждение хотелось бы как-то обосновать. Кто гибче — С или С++? А ведь С++ лаконичнее!
Обосновывать это можно до бесконечности. Для этого как минимум должны быть взаимосогласованные определения. Их не было и не будет. Всех нас всегда будет что то не устраивать. Здесь нечего ответить, поскольку поставьте вопрос на абстракцию выше и вы поймете почему все от всего зависит и выиграть во всем абсолютно не возможно. Каждый выбирает обязательные критерии сам. Главное чтобы выбор был. Вы еще помните концепцию начала и в чем конечный вывод должен состоять?
S>Ага. Это т.н. "классическая квантовая механика". Предполагает, что можно измерить любой параметр с любой точностью. К сожалению, на высокоэнергетических проектах проявляются релятивистские эффекты: нельзя измерить координату с бесконечной точностю, т.к. это потребует бесконечной неопределенности импульса. А она запрещена, p < mc. S>Вот и в программировании так же: некоторые вещи в принципе невозможно реализовать на более простой технологии, т.к. человеко-годы стремятся к бесконечности. Возникает потребность в более производительных инструментах. Парадокс, знаете ли, ахилла и черепахи.
Некоторые вещи могут иметь конечно эквивалентный результат с совершенно различной архитектурой. Ну давайте уж порассуждаем о первостепенных происхождения. Я смотрю мы потихоньку сходим от осязаемого определения к блестанию умом на базе количества и гибкости оперируемых понятий.
A>>Нет ничего абсолютного, есть только достаточное. Поэтому каждому свое. Шарп создавали для прикладников с реализацией устоявшихся понятий, для увеличения скорости и простоты разработки и некоторой степенью защиты от кривых рук, ну и слава богу, и это не обозначает что все это нужно пихать в ++. S>Никто и не предлагает всё это пихать в С++. Просто есть некоторые запросы, на которые С++ отказывается отвечать. Не надо копировать ответы из шарпа; можно было бы копировать и другие ответы. Увы.
Вы знаете точно причину данного отказа. Комитет имеет набор базовых криетриев, за которые ему невозможно вылезть. Отсюда и конечный результат и то что он не для всех достаточен, не значит, что его нет. Есть достаточное количество отличных от вашего мнений, так что равновесие и здесь отказывает вам в абсолютном доступе.
A>>
Sinclair notes:
A>>Дело не в Дженнифер Лопес, а в совершенно объективных и измеримых характеристиках.
A>>Что есть ИЗМЕРИМЫЕ а тем более ОБЪЕКТИВНЫЕ характеристики? S>1. Компактность кода S>2. Количество проверок, выполняемых компилятором
А может тогда уж не будем путать ОБЪЕКТИВНЫХ и СУБЪЕКТИВНЫХ характеристик.
Количественные характеристики компактности и количества проверок, как оценочные характеристики, приведите пожалуйста.
A>>Продолжая сопоставлять и анализировать все вышесказанное, попытайтесь ответить так, чтобы не положить ни на единого хотя бы участника общения. S>Запросто. См. выше.
Отвечу на базе вашей же цитаты:
Вот и в программировании так же: некоторые вещи в принципе невозможно реализовать на более простой технологии, т.к. человеко-годы стремятся к бесконечности.
Запросто. Помимо человеко-лет есть набор составляющих уравнения, которые позволяют откатить человеки годы до вменяемой составляющей с учетом определенного уровня владения. Конечно и это определение сравни бесконечности, но приведено лишь к тому, чтобы, прошу не сочесть за фамильярность, вас убедить в том что вы на грани того чтобы бездоказательно лепить количественные составляющие неопределенной условием структуре.
Здравствуйте, eugene0, Вы писали:
E>Да, но не только. Если художники плохие, то они и крутой движок не спасет. Но это, конечно, не имеет отношения к 3d-акселераторам.
Я бы даже сказал, что хорошие художники важнее крутого движка. Тот же движок Doom3 намного круче Source, но Half-Life2 намного красивее Doom3 и Quake4. Или вот ты приводил Call Of Duty как пример — это же движок Quake3.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>бабки приносите, я вам покажу как их измерить
Приятно что хоть какой то осязаемый результат обсуждения. Хоть развлечься можно
BZ>все эти языки появляются для решения всё техз же извечных задач — уменьшения времени программирвования/отладки, увеличения читабельности и надёжности. в Хаскеле большинство ошибок обнаруживается компилятором.
Указатели есть базовое понятие с достаточной степенью свободы и насколько вы аккуратно проводите анализ составляющих, настолько мала вероятность вами ошибится. Какой проверки на уровне компиляции вы ожидаете, когда указатель имеет лишь один тип, под которым значение адреса. Указание типа лежащего под ним для серфинга по смещениям интересно лишь на момент разыменования, поэтому это ваши проблемы на какой уровень абстракции вы его транислируете и какие определения перекрываете. Касты при определенной вминяемости определяющего очень даже оправданы. Вывернуть наизнанку можна даже абсолютно защищенный протокол определния и оперирования типами. Это языково-независимая аксиома.
Вот теперь продолжайте количественно оценивать читабельность и надежность, иначе сравнивать нечем.
Я и Мы недостаточные характеристики определения.
BZ>чистый результат в моей работе — я написал архзиватор, по возможностям сравнимый я 7zip, но кодом в три раза меньше. подозреваю, что и время разработки было в три раза меньше, хотя это сложнее сравнить.
Если в завтрашнем языке появится базовое понятие типа 7zip, то вам зададут тот же вопрос и так до бесконечности.
Здравствуйте, Sinclair, Вы писали:
E>> Я что-то писал про процессы или потоки? S>Ты — нет. Ты писал про виртуальные машины. Вот, к примеру, каждая Java VM выполняется в отдельном процессе.
Под виртуальными машинами я подразумевал нечто, выполняющее байт-код, получившийся в результате компиляции скрипта.
У нас, например, они вообще все в одном потомке работают, просто опрашиваются по очереди все время.
E>>Зачем что-то колбасить? Вот LUA, вот python. Для того, чтобы делать что-то новое, нужно, чтобы это новое было чем-то лучше, чем готовое и многократно использованное и оттестированное старое. Чем вот эти псевдоязыки были бы лучше? S>Ну, чисто теоретически, они бы еще сильнее контролировали дизайнера. Я, честно говоря, ни LUA ни Python не знаю, поэтому точно сказать ничего не могу. Но я 100% уверен, что дизайнеры не рождаются со знаниями ни того, ни другого. 100% известных мне дизайнеров делятся на тех, кто вообще ни на чем программировать не умеют, и тех, кто немножечко-немножечко знает JavaScript и PHP. S>Я не знаю, почему вы выбрали Lua/Python для своих скриптов. Наверное, из них легче управлять игровыми объектами, чем из С++, и они дают меньше возможностей сделать какую-нибудь катастрофическую ошибку вроде прохода по памяти, использования удаленного объекта или неудаления использованного.
Не совсем так. На мой взгляд, скриптовые языки не предназначены для создания больших сложных систем. Гейм-дизайнеры пишут небольшие скрипты, которые состоят из несложной логики и вызовов API, который предоставляет им движок. Если скрипты стали получаться большие и сложные, значит пора звать программиста, который включит эту сложную логику в игру и создаст для скриптописателей новый интерфейс.
Поэтому требования к скриптовому языку несколько другие: простота, читаемость и желательно какая-нибудь интерактивность, чтобы написанный скрипт можно был тут же и запустить.
В таких условиях написание скриптов на "взрослых" языках вроде C# или джавы или C++ выглядит как стрельба из пушки по воробьям.
мировать не умеют, и тех, кто немножечко-немножечко знает JavaScript и PHP. S>>Я не знаю, почему вы выбрали Lua/Python для своих скриптов. Наверное, из них легче управлять игровыми объектами, чем из С++, и они дают меньше возможностей сделать какую-нибудь катастрофическую ошибку вроде прохода по памяти, использования удаленного объекта или неудаления использованного. E>Не совсем так. На мой взгляд, скриптовые языки не предназначены для создания больших сложных систем. Гейм-дизайнеры пишут небольшие скрипты, которые состоят из несложной логики и вызовов API, который предоставляет им движок. Если скрипты стали получаться большие и сложные, значит пора звать программиста, который включит эту сложную логику в игру и создаст для скриптописателей новый интерфейс. E>Поэтому требования к скриптовому языку несколько другие: простота, читаемость и желательно какая-нибудь интерактивность, чтобы написанный скрипт можно был тут же и запустить. E>В таких условиях написание скриптов на "взрослых" языках вроде C# или джавы или C++ выглядит как стрельба из пушки по воробьям.
собственно, всё то же, что и принаписании скриптов в ОС. почему для этого используют bash, awk, perl, а не C#? вопрос риторический
я лично предпочитаю писать скрипты на ruby. для сравнения пробовал haskell — некоторые вещи в нём проще (ну я тут уже приводил три примера ), некоторые — сложнее (императвиность), в целом вышло баш на баш. какой-нибудь императивный функциланльый интерпретируемый язык типа окамл был бы наверно идеалои для меня
Здравствуйте, VladD2, Вы писали:
DC>>Влад кто из производителей движков/ОС/драйверов переходит на Немерле/ОКамл/... VD>Самые умные.
А можно поименно?
VD>>>Второе покоеление уже писалось с использованием скриптов и С++. DC>>Использование скриптов ИМХО еще позже появилось. VD>Погляди Анрэл 1.
Quake 1 — QuakeC — компилируемый язык с VM.
DC>> Где 3Д библиотеки для Немерле/ОКамл/... которые удовлетворяют разработчиков движков? VD>Они прекрасно исползуют имеющиеся бибилотеки. Для Немерле будет радным XNA, от МС
Ой только не надо про %НЮ. Потому как кроме как нецензурно о этой поделке отозваться не могу... Шшупали...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, VladD2, Вы писали:
VD>>>Данные похожие на данные из приводимой мной презентации, но они мало что говорят об оправданности такого решения. VD>>>Из той же презентации видно, что на всю симуляцию игры уходит около 10% процессорного времени: E>><таблицу поскипал>
Ok, я наконец ее посмотрел. Любопытно, спасибо.
Из забавного:
Solved problems:
Random memory overwrites
Memory leaks
Solveable:
Accessing arrays out-of-bounds
Dereferencing null pointers
Integer overflow
Accessing uninitialized variables
50% of the bugs in Unreal can be traced to these problems!
Даже не знаю, что сказать. У нас эта цифра составит, наверное, процентов 10. Т.е. за весь проект мы не видели ни одного проезда по памяти. Утечки в начале были, но после того, как всем программистам объяснили, что такое смартпоинтер, об утечках тоже забыли и не вспоминают уже года два. Массивы мы не практически используем, пользуемся контейнерами STL, с ними вылезти за границы сложнее. Обращению к нулевому указателю проявляют себя немедленно и тут же исправляются. Integer overflow не видал. Неинициализированные переменные — это да, проблема.
У нас главная проблема — это макароны и все, что с ними связано. Неправильная декомпозиция или ее отсутствие. Решения типа "сейчас пускай заработает, а потом я сделаю правильно" (а потом он уволился). Куски кода, к которые последовательно приложило лапу 2-3-4 человека, и никто уже не помнит, что он там и зачем делал.
Но это так, к слову.
Я в целом поддерживаю автора: неплохо бы получить новый, эффективный язык, лишенный недостатков того, что мы иcпользуем сейчас!
Правда, главный аргумент тут — это грядущая всеобщая многопроцессорность/многоядерность. До тех пор, пока можно работать в одном-друх потоках без ущерба для производительности, С++ в принципе подходит. Да, у него много недостатков, всяких раздражающих фич и пережитков прошлого, но работать можно.
E>>Если я правильно понимаю, поскипанная мной таблица — нечто вроде данных профайлинга, на что ушло больше процессорного времени? VD>Нет совесм, это оценки авторов Анрыла. Там не только процессороное время. E>>Если интересно, могу привести _наши_ данные, полученные от профайлера. VD>Конечно интересно.
Тут есть затруднение. Дело в том, что профайлер выводит статистику по функциям. Game simulation и numeric computation там довольно сильно перемешаны. Я прямо сейчас не смогу ручкми все это посчитать, нету времени. Возможно, позже.
E>>Конечно же, я с удовольствием писал бы на удобном и безопасном языке. Вопрос только в том, сколько все же составляют те самые проценты, на которые он медленнее неудобного и опасного, но более быстрого языка.
VD>Хохма заключается в том, что величина эта переменная и обычно она не превышает статистической пограшности. Алгоритмические просчеты или просто выбор не оптимальных путей дает куда больший проигрышь. Единственное что действительно приносится в жертву — это расходуемая память. GC показывает хорошую скорость только если занимает память с запасом. Плюс есть собсвтенные накладные расходы. Так что получается, что расход памяти у дотнета на уровне скриптовых языков.
То, что ест много памяти, плохо Мы сейчас как раз пытаемся впихнуть игру в 512 мегов, пока не очень успешно.
E>>Предлагаю говорить все же более конкретно. Скажем, 10% для нас — это уже критично. У нас пока некоторые уровни на средних машинах на слайд-шоу похожи
VD>Дык. Тут уже язык мало что може сделать. Тут нужна или акселерация, или изменение алгоритмов. А на них нужно время. А оно уходит на больрбу с С++. Идея ясна?
Идею, которые ты двигаешь в массы, я понял уже давно Но, как видно из начала сообщения время уходит не столько на борьбу с С++, сколько на борьбу с ошибками проектирования и организации разработки.
На самом деле, идея попытаться переписать менее критичную по производительности часть проекта на C# когда-то была, но было не вполне понятно, как совместить управляемый код с неуправляемым, ну и времени, как обычно, не хватило.
VD>>Дык. Тут уже язык мало что може сделать. Тут нужна или акселерация, или изменение алгоритмов. А на них нужно время. А оно уходит на больрбу с С++. Идея ясна?
E>Идею, которые ты двигаешь в массы, я понял уже давно Но, как видно из начала сообщения время уходит не столько на борьбу с С++,
Здравствуйте, eugene0, Вы писали:
E>Утечки в начале были, но после того, как всем программистам объяснили, что такое смартпоинтер, об утечках тоже забыли и не вспоминают уже года два.
Вот это меня всегда особенно забавляло. С одной стороны адресная арифметика представляется нам как одно из фундаментальных средств, позволяющих использовать плюсы как язык для написания эффективных программ. С другой, абсолютно все вменяемые девелоперы, с которыми я когда либо общался, душат голые указатели на корню с помощью всевозможных костылей в виде смарт-поинтеров.
Где логика я вас спрашиваю?
Если нам не помогут, то мы тоже никого не пощадим.
IT>Вот это меня всегда особенно забавляло. С одной стороны адресная арифметика представляется нам как одно из фундаментальных средств, позволяющих использовать плюсы как язык для написания эффективных программ. С другой, абсолютно все вменяемые девелоперы, с которыми я когда либо общался, душат голые указатели на корню с помощью всевозможных костылей в виде смарт-поинтеров.
IT>Где логика я вас спрашиваю?
"вот из-за того, что вы говорите не то, что думаете, и думаете не то, что думаете — мы здесь и наблюдаем весь это горький катаклизм"
BZ>>представьте себе ассемблер с ООП расширениями, шаблонами, клозурами, монадами, примитивами синхронизации и т.д. смешно? было бы смешно, если б не было близко к правде. С появился как язык системного программирования, высокоуровневый ассемблер, и именно благодаря своей эффективности, близости к железу он завоевал симпатии в мире ранних мини-компьютеров и персоналок, с их скромными ресурсами
A>Теперь не применительно только к этой фразе а вывод в общем. Каждый инструмент создается as main concept для определенных задач. Кто то ниже говорил "разделять сервер и морду". Я совершенно с этим согласен и как видишь даже в бессмысленный спор не вступаю. Вопрос лишь в том кто будет морду реализовать. A>Я прекрасно представляю ассемблер с шаблонами и примитивами синхронизации, но и вы представте C# в виде монстра, который решает не только задачи прикладного програмирования, а еще и будет перекручен конструкциями с определенными unmanaged оговорками для свободного манипулирования ресурсами под уровень ядра, либо все таки МС придется извратится чтобы все возможные варианты изобразить MSIL компилером. Все равно это будут не логичные для его контекста описания. Вообщем заметьте Г. получается как с одной, так и с другой стороны. Не нужно все это. A>Пускай C++ занимается задачами в своем стиле и не нужно ему всего что касается managed расширений. Человек, который не хочет следить за ресурсами сам, либо не умеет оперировать типами, пускай не лезет в ++ (это не характеризует недостатки языка). При правильном архитектурном подходе, я поверь мне уже практически избавился от страшных снов связанных с этим, абсолютно. Каждый инструмент требует определенных навыков, опыта и мозгов. Кесарю, кесарево. Железная истина. Для прикладников языки другие.
что C# с unmanaged code, что C++ с его managed расширениями типа smart pointers — это фактичсеки два разных языка за цену одного
можно считать, что я пошёл ещё дальше и весь прикладной код пишу на хаскеле, а низкоуровневый — на C++ и не требую ни от того, ни от другого языка неестественных для него трюков. что касается арзитектурного подхода, то я тоже когда-то отладивал C с помощью printf'ов. можно чему угодно обезьяну научить но всё же лучше потратить силы на то, чтобы научиться писать более сложные программы с современными языками, нежели учиться делать несложные вещи, которые становятся сложными из-за устаревшего инструментария
BZ>>в 80-х ...
A>Хватит о них. Мне 33 и я помню о них прекрасно. По моему до сих пор в обсуждении остались только люди, которые хоть как то ориентируются во всем этом флейме, не воспримите за оскорбление.
вы в 80-е программировали? да ещё и отслеживали все события в мире компилтяоров?? я-то просто недавно надыбал dr dobbs за эти годы и с удовольствием отследил борьбу и языков, и компиляторов. кол-во компиляторов C, паскаля и модулы было тогда практически одинаковым — 5 модул, шутк 6-7 Си. ну и ещё интерсено вспомнить, что С++ пошёл только потому, что разработчики были уверены, что на нём можно будет писать программы не медленней, чем на C
BZ>>однако когда речь доходит ло прикладного программирования и эффективность оказывается не главным, тут С++ напоминает Винни-Пуха, который прикидывался тучкой в языке нет GC и type-safe generic references, синхронизации, клозур и т.п. ну и фиг с ним! мы всё это сэмулируем! в результате чего есть язык С++, содержащий массу конструкций, которые прикладному программисту просто не следует использовать, и многочисленные бибилиотеки, которые худо-бедно эмулируют возможности, напрямую встроенные в другие, более современные языки
A>Вот и пускай будут они туда встроены. !!!! О БОЖЕ, мы наконец приходим к тому, к чему с самого начала стремились. A>1. Я счастлив, что простому прикладнику наконец сделали инструменты, которые позволяют меньше думать и больше работать, но это отнюдь не означает что С++ плох. Ему просто все эти расширения не нужны. A>2. Если человек владеет С++ — это должно четко обозначать что он в состоянии за время не меньшее, чем прикладник с помощью своего инструмента, может эмулировать все те вещи о которых мы говорим. A>Для меня это кристальная истина. Все остальные лишь используют язык, в каких то узких целях, который им возможно и не нужен.
давайте это по-другому выразим. спец C++ , по-вашему — это человек, который в несколько раз дольше учился, в несколько раз больше работает, и в конечном счёте получает ровно то же, что и спец в более современно языке? "товарищ сержант, ну можно я веником подмету?"
знаете, что меня к хаскелу привело? я вроде тоже неплохой спец по C++ был, мой арзиватор arjz широко известен в узких кругах. и прикинув, на что больше всего времени тратится при разработке архиватора, я решил, что с (тогдашним) С++ мне не по пути. нужны гибкие структуры данных с мощными возможностями по их обработке, нужны клозуры, весьма желателен gc. C++ — по своей сути просто препроцессор, генерящий чисто императивный код, какая-нибудь фиговина типа map+sort без промежуточных переменных уже способна повергнуть его в ступор.
сначала я наткнулся на перл — отличная вещь, но с динамичсекой типизацией и хернёй при использовании вложенных структур данных. как на нём большие проекты пишут — я до сих пор пораджаюсь, такие же герои дисциплины, как и вы
затем на руби, в нём замечательная объектная модель, клозуры, но язык всё же динамический со всеми вытьекающими отсюда ненадёжностью, медленностью и т.д.
ну и наконец — на хаскел с его строжайшей типизацией, развитой системой типов и лёгкостью описания сложных алгоритмов. то есть nemn и надёжность (которую со временем начинаешь ценить всё больше), и выразительность
я собственно не так давно поработал ведущим программистом в асу тп конторе, мы писали как раз на BC 3.1 под контроллеры. мне неинтересно на этом C++ писать — слишком примитивный язык, многие проблемы приходится решать путём тупого копирования кода. поэтому я только раздавал руководящие указания а на хаскеле мне писать интересно, поскольку уровень языка соответствует уровню моего мышления — то, что мне легко вообразить, легко записать и на хаскеле. я не зря те три примера хаскеловского кода приводил — они напрямую описывают то, как я вижу решение задачи. ну вот возьмите хоть это:
-- |this function finds last space in String within 80-char boundary
len_f = last . filter (<80) . findIndices (==' ')
если начать её переписывать на C, то выйдет много дурацких описаний, временных переменных, циклов. верно? вот это и есть, на мой взгляд, "подметать плац ломиком". и поиметь здесь на C скорость разработки такую, как у меня, вы можете видимо только за счёт навыков отличной машинистки
то есть хаскелл соответствует тому, как я думаю. я на нём не вгоняю себя в рамки искусственной дисциплины, не "эмулирую все те вещи", не "избавляюсь от стращных снов". я просто творю, естественно и прямолинейно. человек должен работать, машина думать — так, кажется, говорят в ibm?
A>В языке достаточно минимально необходимых примитивов для эмуляции чего угодно. Все что нельзя сделать, неправильно концептуально спроектировано
это вы про машину Тьюринга?
A>То что язык развивается в сторону метапрограммирования на базе шаблонов — это совершенно логичесное и естественное развитие языка данного уровня.
высокоуровневого ассеблера? да. но для написания эффективных программ шаблоны особо и не нужны, а для написания прикоадных программ лучше испольщзовать более высокоуровневые средства. у макросов, даже в таком виде, свои недостатки — сообщения об ошибках, отсутствие run-time поддержки, время компиляции
BZ>>вот поэтому вы и need a complex language — чтобы созранить совместимость с кодом 30-летней давности, сгенерить как можно более эффективную программу, а затем попытаться как-то сэмулировать современные языки.
A>Что вы так пристали к этой совместимости. Она остается до сих пор только потому, что нет смысла язык наворачивать не свойственными ему вещами изначально. A>Если для вас совместимость главный критерий, то для меня абсолютно. Я уже ранее говорил, что в определеной степени владения языком нет проблем в эмуляции того о чем мы говорим. Просто кто то — это сделает быстрее, а кто то не сделает вообще и то что язык требует более высокого уровня skills — это не недостаток его, а лишь характеристика.
совместимость с BCPL — это ограничитель развития самого C++. ну ни к чему в один язык тащить все aborb? которые когда-либо были изобретены. а когда тащат и начинают всё вместек совмещать, "эмулировать" — тогда и выходит коктейль из switch'a с лямбдой
BZ>>я тут выше приводил пару примеров кода в хаскел, напиши их аналоги в С++ и сравни сам. если вместо изучения всех этих legacy features и методов эмуляции modern features изучать напрямую современный язык, то ты здорово сэконишь во времени изучения и затем во времени написания/отладки кода.
A>может ведь и не хватить мозгов ее отладить даже в такой среде. все относительно. A>на времени обучения сильно сэкономишь, но сильно проиграешь в развитии и гибкости.
ну с таким подходом мы вообще должны сами проектировать кмпьютер для решения каждой новой задачи — гибче некуда. ИНДУСТРИЯ программирования развивается в сторону того, чтобы выделить паттерны, обобщить их и внести в методолгию/язык/whatever. это повышает призводительность труда, а производительность труда, по Марксу — это мерило степени развития общества помню, как мне один амер в 90-х говорил "не занимайся ассемблерной оптимизацией, брось бяку!", а я ему не верил сейчас я вам говорю то же самое, сыны мои
РАЗВИТИЕ ПРОГРАММИСТА ОПРЕДЕЛЯЕТСЯ УРОВНЕМ ЗНАНИЯ СОВРЕМЕННЫХ ТЕХНОЛОГИЙ, А НЕ СПОСОБНОСТЬЮ СЭМУЛИРОВАТЬ ИХ ЧЕРЕЗ СТАРЫЕ. по очень простой причине — деньги. быстрее делаешь программу — длиннее деньги. а для интереса я и сам с удовольствием C++ со всеми его наворотами прочту (но зазубривать не стану, и не просите )
BZ>>именно об этом я и говрю — что в С++ thread-safe программирование требует специального изучения и в job offers, например, указывается как отдельное требование чтобы понять, насколько это смешно, представьте себе скажем требование "умение вызывать функции рекурсивно". это тоже может специальным умением в языке типа Фортрана, где это не поддерживалось
A>Сравнивать "рекурсивный вызов" и "thread-safe" — это все равно что в правах на вождение автомобиля указывать уровень владения самокатом. Давайте не опускаться до такого уровня. Человек ничего не знающий о потоках и разделяемых ресурсах и в C# репу перегреет такими понятиями как ThreadMutex и т.д.
ха! вот тут-то я вас и подловлю. прежде всего — вы представляете, какого уровня знаний требует рекурсвиное порграммирование на фортране IV? для рекурсивного вызова нужно завести по массиву на каждую локальную переменную, и хранить номер текущего используемого индекса в этом массиве. затем нужно обеспечить переход к нужной части порцедуры при вовзрате. но это ещё фигня — предствьте себе взаиморекурсивные вызовы нескольких порцедур!!! нынешние пограммисты и не подозревают, как много им сил сэкономили компиляторы
а теперь посмотрите как записывается многопоточная программа на хаскеле:
-- Thread, который в цикле читает команды из потока и исполняет их
graphThread c = do cmd <- getChan c
cmd
graphThread c
-- Создаёт graphThread и посылает ему команды на исполнение
main = do с <- newChan
forkOS $ graphThread c
putChan c (print "Hi")
tid <- forkOS $ putChan c (print "Hi from other thread")
putChan c (print "Bye")
waitThread tid
а теперь скажите, что легче — написать рекурсивную программу на фортране, или многопоточную, с автоматичсекой синхронизацией и разделением ресурсов — на хаскеле? и стоит ли хаскелловскому порграммисту указывать умение писать такие порграммы как отдельный скилл?
это кстати пример из реальной жизни. одному моему знакомому понадобилось такое написать, когда выяснилось, что граф. библиотека умеет принимать команды только из одного потока, а ему потребовалось посылать их из нескольких. в данном случае различные треды посылают потоку graphThread колманды print, а он их по очереди выполняет. и как этот человек мне писал — он был просто поражён тем, как элементарно оказалось в этом разобраться и запрограммировать
у меня было аналогично. когда я решил присобачить к своему арзиватору read-ahead, опережающее чтение файлов в отдельном от упаковки треде, я потратил неделю. на то, чтобы во всём этом разобраться, и чтобы осознать, КАК это просто будет сделать. у меня просто мозги этого не совпринимали, как и ваши наверно сейчас разобравшись, я сделал за день, там строк 40 кода всего понадобилось. а вот ни в одлном из других арзиваторов этого до сих пор нет. почему? наверно, потому, что они все на C++ написаны
то же самое относится и ко многим другим архиваторным фичам. у меня более интеллектуальная сортировка, разбиение на солид-блоки, выбор алгоритма сжатия и т.д. может, Рошаль и Павлов в вашей классификации и не специалисты по C++, но по крайней мере я их по многим фичам обхожу
BZ>>т.е. опять речь о complex language, порождённом тем, что современные концепции программирования в нём — нечто дополнительно прикрученное сбоку с теми самыми километрами художеств
A>Где явное определение того, что так называемый complex language охватывает весь спектр современных концепций и что есть весь спектр современных концепций? A>Я надеюсь понятно без лишних объяснений почему вам не удастся быть объекивных в этой части вопроса.
а мне кажется — можно multi-threading, GC, лямбды и прочие вещи, которые в других языках есть изначально, и умение пользоваться эмуляцией которых в C++ рассматривается как необходимое условие для устройства на работу
<...поскипано...>
BZ>ну и наконец — на хаскел с его строжайшей типизацией, развитой системой типов и лёгкостью описания сложных алгоритмов. то есть nemn и надёжность (которую со временем начинаешь ценить всё больше), и выразительность
<...поскипано...>
BZ>а теперь посмотрите как записывается многопоточная программа на хаскеле:
BZ>
BZ>-- Thread, который в цикле читает команды из потока и исполняет их
BZ>graphThread c = do cmd <- getChan c
BZ> cmd
BZ> graphThread c
BZ>-- Создаёт graphThread и посылает ему команды на исполнение
BZ>main = do с <- newChan
BZ> forkOS $ graphThread c
BZ> putChan c (print "Hi")
BZ> tid <- forkOS $ putChan c (print "Hi from other thread")
BZ> putChan c (print "Bye")
BZ> waitThread tid
BZ>
BZ>а теперь скажите, что легче — написать рекурсивную программу на фортране, или многопоточную, с автоматичсекой синхронизацией и разделением ресурсов — на хаскеле? и стоит ли хаскелловскому порграммисту указывать умение писать такие порграммы как отдельный скилл?
<...поскипано...>
Вы меня, конечно, извините, но в ваших словах мне так и слышится бравада: "Я освоил Хаскел! Я проперся от него! Я познал неведомое доселе!". И вспоминается мне один очень талантливый мужик, фанат Пролога, который несколько лет назад написал на Прологе офигенную систему. В которой никто не мог разобраться кроме него. Более того, когда однажды потребовалось выяснить причину ее странного поведения в какой-то ситуации, на вопрос "А как она вообще работает" он ответил -- "А хрен его знает". И закончилось все, как и можно было ожидать, тем, что после его ухода все творение было в довольно короткий срок переписано на C++ парой вчерашних студентов. И работало затем несколько лет без нареканий. Причем те студенты сейчас ведут еще более серьезные проекты и слова Хаскел, я думаю, даже не слышали.
И так бывает, однако.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Если ты видел только MFC, ATL и C++Builder, то это не значит, что GUI всегда было геморроем.
Твои преположения опять мимо кассы.
VD>>Я тебе на C# напишу такое ГУИ в десятки раз быстрее, проще и надежнее.
E>Во-первых, сложность не в GUI. E>Во-вторых, написанный тобой GUI я имел возможность наблюдать, пользуясь некоторое время назад Янусов. В сад такое быстрое, простое и надежное GUI на C#.
Из ГУИ януса я делал только дерево.
В общем, твоя манера сводить все разговоры к переходу на личности меня достала.
Сам то ты что написал, что можно пощупать и оценить быстроедействие?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>К системным задачам относят не только компиляторы и драйверы.
Не может быть?! Спасибо, ты мне открыл глаза. И какие же еще? Уж не СОбжектайзер ли?
E>Нифига это не одно и тоже. BitTorrent-у не нужно реагировать на случайным образом возникающие события он просто занимается перекачкой данных.
Ясно, ясно. Все программы что ты не видел ничего не делают. Кто бы сомневался. Это же не СОбжектайзер. Он постоянно отслеживает десятки, а то и сотни параллельно ралботающих torrent и выводит информацию о них (ксолько чего от кого или кому скачалось и т.п.). Причем эти параллельные клиенты постоянно исчезают и появляются.
VD>>Как не странно дрова и сетевые протоколы в Сингулярити написаны на C# и не уступают в эффктивности Линуксу с Виндовс.
E>Где не уступают? Где есть хотя бы одна промышленно используемая система на Сингулярити, работающая в режиме 24x7?
Нет необходимости в промышленных системах чтобы доказать что это так. Люди сделали тесты и представили их результаты людям. Оставь свою демагогию при себе. Это факт.
E>>>Вообще-то на моей памяти максимальные оценки здесь получали как раз внезапно появляющиеся адепты функционального программирования, которые начинали рассказывать разные необычные для mainstream-программистов вещи.
VD>>Ну, ты то к ним не относишся и в топе форума.
E>Из любого правила есть исключения.
Но это не ты.
E> Ты, кстати, не далеко от меня обосновался, так что ктобы жаловался
А я в функциональщики перевербовался.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
DC>>>Влад кто из производителей движков/ОС/драйверов переходит на Немерле/ОКамл/... VD>>Самые умные. CC>А можно поименно?
Нельзя. Это коммерческая тайна.
VD>>>>Второе покоеление уже писалось с использованием скриптов и С++. DC>>>Использование скриптов ИМХО еще позже появилось. VD>>Погляди Анрэл 1. CC>Quake 1 — QuakeC — компилируемый язык с VM.
Кармак все еще и на С пишет. Это не показаоель. Показатель скорее то, что он просрал очередной виток технологий ФарКику.
DC>>> Где 3Д библиотеки для Немерле/ОКамл/... которые удовлетворяют разработчиков движков? VD>>Они прекрасно исползуют имеющиеся бибилотеки. Для Немерле будет радным XNA, от МС CC>Ой только не надо про %НЮ. Потому как кроме как нецензурно о этой поделке отозваться не могу... Шшупали...
А кто ты такой чтобы твое мнение по этому поводу было интересно?
МС же компания которая привыкла доводить начинания до конца. Так что XNA будет стандартом хоть ты в штаны наложи, а DirectX и OpenGL сегодняшние стандарты которые уже давно можно прекрасно использовать из того же Немерла. Так что скипай, не скипай, а это факты.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Вы меня, конечно, извините, но в ваших словах мне так и слышится бравада: "Я освоил Хаскел! Я проперся от него! Я познал неведомое доселе!". И вспоминается мне один очень талантливый мужик, фанат Пролога, который несколько лет назад написал на Прологе офигенную систему. В которой никто не мог разобраться кроме него. Более того, когда однажды потребовалось выяснить причину ее странного поведения в какой-то ситуации, на вопрос "А как она вообще работает" он ответил -- "А хрен его знает". И закончилось все, как и можно было ожидать, тем, что после его ухода все творение было в довольно короткий срок переписано на C++ парой вчерашних студентов. И работало затем несколько лет без нареканий. Причем те студенты сейчас ведут еще более серьезные проекты и слова Хаскел, я думаю, даже не слышали.
В его словах я вижу не браваду, а разумные мысли. Я бы возможно поспорил по поводу выбора современного языка, но Хаскель тоже один из них это точно.
А в твоих словах я вижу как раз бараваду. Да не простую браваду, а снобистскую браваду посредственностью.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, VladD2, Вы писали:
VD>>Они локаничны, но совершенно не понятны. S>Лаконичность нужно мерить не в символах, а в синтаксических элементах.
Тоже не совсем прокатывает. Локоничность можно добиться введя уйму умолчаний. Ну, например, передавая контекс через глобальные переменные как в Руби. Только это плохая локонпчность.
S> Иначе мы получим рассуждения С.Г. о "синтаксическом оверхеде", а замена всех имен переменных на одно-двух-символьные сочетания должна будет существенно упрощать программу.
+1
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
VD>>С++ компактнее С только при условии, что на С код пишется в объектно-ориентированном стиле. ООП позволяет решать более сложные задачи за счет ОО-декомпозиции. Но кода получается обычно даже больше. S>Нет. Шаблонные функции тоже рулят, т.к. позволяют не писать отдельные версии на каждый тип.
Рулят, рулят. Только моих слов это не изменяет. ООП для очень многих задач является оверкилом.
S>Кстати, K&R C, руливший во времена С++, все еще не позволял указывать типы аргументов в объявлениях функции и требовал объявлять все переменные только в начале.
Это не так. В времена С++ уже был ANSI C. Плюс K&R исходно позволял объявлять параметры по месту. Просто он же позволял и выносить их. Лично я K&R уже не застал. Хотя программирую на С с 93-его.
S> Насколько я помню, возврат структур также был запрещен (могу ошибаться). Ссылок в С тоже не было.
Ссылки — это сахар. Указатели решают все проблемы кроме проблемы кривых указателей.
Вот только ты ушел от емы слишком даеко.
VD>>Но на С можно писать и в фукнциональном стиле, и в простом структрном, процедурном. При этом иногда даже получается более краткий и понятный код. S>Короче, чем на С++ уже не получится, т.к. такая программа автоматически будет и С++ программой.
Нет, получится, так как это как раз уже С++-ный код написанный в ограничениях С будет С-шным. А реализовав ту же задачу в "традициях" С++ мы получим оверкил.
И это не гипотетические сказки. Я сам видел изумительные примеры классов преобразования чисел в строки.
S> Более того, структурно-процедурная программа на С++ будет скорее всего компактнее, чем на С, благодаря всяким простым штукам навроде наследования структур, которого не было в С.
Ну, вот практика показывает, что — нет. На С тоже можно писать довольно компактно. И так как людям эмуляция ООП стоит дорого, то они сто раз думают какие паттерны применить (для С++, что ООП, что ФП, все паттерны). А на С++ сразу лепят классы. Так ведь учили.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
E>По моему опыту, сложность AI ограничивается вовсе не производительностью процессора. У нас AI не тормозит. Что угодно тормозит, рендер, анимация, та же физика, а вот AI нет. E>IMHO проблема тут не в производтельности, а в сложности реализации сложных моделей поведения, а также, в некторых случаях, в целесообразности этого.
Дык и целесообразность, и сложность определяются возможностями человеческого интелекта и вычислительными возможностями системы на котором работает ПО.
Первое можно повысить исползуя более мощьные инструменты, но они скорее всего будут не так эффективны как низкоуровневый код. А второе даже и обсуждать нет смысла. Ведь более умный герой однозначно будет жрать больше процессорного времени.
E>Сложность AI не означает интересности игры. Во многих 3D-шутерах сложную логику поведения врагов просто никто не оценит. Q3 изначально был нацелен на multiplayer, боты там, по-моему, вообще больше для тестов и начальной тренировки новичков. Ну если ты все же играешь в Q3 один, какого усложненное поведение ты хотел бы у них увидеть?
Поведения неотличимого от человека. Боты в найтмаре очень похожи на человека с отличной реакций, но совсем тупого. А хочется, чтобы они делали подляны... прятались и собирали предметы когда у них мало здоровя/брони, наоборот пресинговали когда захватят ресурсв. И чтобы они мазали не рандомом, а в зваисимости от сложности обстановки. Ну, блин, противно видеть как бот попадает в тебя совершая кульбит в другом конце уровня! И наоборот, мажет в упор.
В общем, хочется ума. Хочется чтобы бот радомом выбирал только одну из хороших стратегий, и хочется чтобы стратегии у него были.
И тут без паттерн матчинга или даже без логики предикатов никак не обойтись.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eugene0, Вы писали:
E>У меня такое ощущение, что я заигрался в адвоката дьявола. А я всего лишь хотел сказать, что физика — не так важна для игры, как, к примеру, красивая графика, и поэтому сравнивать ускоритель физики с 3D-акселератором неправильно. На самом деле я не против физики, нет.
Может я необычен, но я с большим удовольствие прошел Постал 2 где графика была так себе, и мне было довольно скучно идти в Думе 3 и даже в Прэее (на последних уровнях). В ХавЛайфе 2 меня тоже задалбовали месильные части где надо было отстреливаться и выполнять тупые квесты, а радовали разные приколы с гравипушкой и красивые физические эффекты.
Я конечно только "за" хорошую графику, но без хорошей физики, хорошей режисуры, и хорошиго сюжета ничего не выйдет.
Кстати, все миденные мной игры с точки зрения погуружения и сюжета мне все же не понравились. Хочу побыть первым терминатором или охранником из "Зеленой мили", так чтобы жить в сюжете, а не наблюдать как программист и дизайнер уровня направляет меня к следющей двери.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eugene0, Вы писали:
E>Поэтому требования к скриптовому языку несколько другие: простота, читаемость и желательно какая-нибудь интерактивность, чтобы написанный скрипт можно был тут же и запустить. E>В таких условиях написание скриптов на "взрослых" языках вроде C# или джавы или C++ выглядит как стрельба из пушки по воробьям.
С++- конечно. А вот два других как раз более мем могут быть преспособлены для решения данной задачи. Ну, и конечно есть третий наличие которого делает бессысленым все три и скрипты в придачу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>я лично предпочитаю писать скрипты на ruby. для сравнения пробовал haskell — некоторые вещи в нём проще (ну я тут уже приводил три примера ), некоторые — сложнее (императвиность), в целом вышло баш на баш. какой-нибудь императивный функциланльый интерпретируемый язык типа окамл был бы наверно идеалои для меня
А зачем интерпретирвемый?
ЗЫ
У ОКамла проблемы с черезмерной строгостью и статиченостью. Компонентность он поддерживает хуже чем С++.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eugene0, Вы писали:
E>Даже не знаю, что сказать. У нас эта цифра составит, наверное, процентов 10.
Извини, но мой опыт не позволяет мне с тобой согласиться. Да и доверия этому товарищу все же больше. Как ни как в Анрыл я играл чуть ли не 10 лет назад.
E>Т.е. за весь проект мы не видели ни одного проезда по памяти.
Значит вы его просто пока не сдали.
E> Утечки в начале были, но после того, как всем программистам объяснили, что такое смартпоинтер, об утечках тоже забыли и не вспоминают уже года два.
Вот она ключевая фраза — "уже года два"! То есть вы убили время еще тогда, и теперь еще 2 (!) года возитесь с проектом! А могли бы ВООБЩЕ не возиться с этими проблемами!
E> Массивы мы не практически используем, пользуемся контейнерами STL, с ними вылезти за границы сложнее.
Сложнее не значит невозможно. Подставь end от нетого итератора и вуаля... Ты вот меня уверяешь, что проблем у вас нет, а меж тем ошибся в предложении выше без проблем "Массивы мы не практически используем" по-русски значит, "используем не практически", а не то что ты хотел сказать "не неиспользуем на практике". Вот такие же ошибки у вас сплош и рядом в С++. Понятное дело, что вы их исправляете, но на это уходит много времени. И самое обидное, что какие-то из них все равно остаются в программе.
E> Обращению к нулевому указателю проявляют себя немедленно и тут же исправляются. Integer overflow не видал. Неинициализированные переменные — это да, проблема.
Это если ты его тут же умудрился обнаружить. Но язык то у етбя ОО, и без проблем можно поиметь обнуленное поле. А выяснить почему оно обнулено не так то просто. Так вы и приходите к тому, что проект делается годами. Плюс вместо нуля может быть грязь. Причем в дебаге одна, и все пашет, а в релизе другая и ничего не работает без объяснения причин.
E>У нас главная проблема — это макароны и все, что с ними связано.
А ты представь себе на минуточку, что автор презентации организовал работу так, что код у них стал хорошим. Вот он и высказывает свои мысли о том как еще улучшить процесс разработки.
E> Неправильная декомпозиция или ее отсутствие. Решения типа "сейчас пускай заработает, а потом я сделаю правильно" (а потом он уволился). Куски кода, к которые последовательно приложило лапу 2-3-4 человека, и никто уже не помнит, что он там и зачем делал.
Это тяжело объяснить, но поверь, все перечисленное тобой умножается на проблемы языка. Вот вы и получаете 2 года разработки после того как какзалось бы всем все объяснили.
К тому же ты вдумайся в свои слова "объяснили всем что надо". Это значит, что вы ограничили язык до некого сабсета. Причем контролирвать это будут люди. Ты конечно потом сможешь позлорадствовать, что мол эти козлы наколбаслии, да я бы такоего никогда не допуситл... но время уйдет. По этому все что может контролировать машина должна контролировать машина. А твоя задача сфомрмировать процесс производства ПО так чтобы этот контроль был. Сюда входит выбор инструмента, и выработка тех.процессов.
E>Но это так, к слову. E>Я в целом поддерживаю автора: неплохо бы получить новый, эффективный язык, лишенный недостатков того, что мы иcпользуем сейчас!
Дык, мы как раз о том и говори, что такие языки уже появились.
Не все конечно идеатльно, но с С++ точно не сравнить. Вот BulatZiganshin хвалит Хаскель. Правда у Хаскеля много своих проблем. И об этом как раз и говорит автор презентации. Но вот Немерле очень близок к этому идиалу. К тому же его можно подстрагивать под задачу.
E>Правда, главный аргумент тут — это грядущая всеобщая многопроцессорность/многоядерность. До тех пор, пока можно работать в одном-друх потоках без ущерба для производительности, С++ в принципе подходит. Да, у него много недостатков, всяких раздражающих фич и пережитков прошлого, но работать можно.
Многопроцессорность — это одно из изменнеий в мире. Но не единственное. Другими являются появление огромных объеемов памяти, крутых акселераторов, и конечно же, новых мощьных языков программирования и библиотек/RAD-средств.
С++ используется исключительно потому что это прокатанный путь.
E>Тут есть затруднение. Дело в том, что профайлер выводит статистику по функциям. Game simulation и numeric computation там довольно сильно перемешаны. Я прямо сейчас не смогу ручкми все это посчитать, нету времени. Возможно, позже.
ОК, если будет время попробуй.
E>То, что ест много памяти, плохо Мы сейчас как раз пытаемся впихнуть игру в 512 мегов, пока не очень успешно.
На XBox используется более экономный GC. Незнаю как он в плане производительности, но в 512 метров вроде игры влазят.
К тому же 512 это сегодня. Игра которую начнут делать сегодня будет готова через год-два, а там глядишь и гиг будет стандартом.
К тому же имея более мощьный язык ты можешь уделить больше времени оптпимизациям. Да и делать их автоматизировано.
E>Идею, которые ты двигаешь в массы, я понял уже давно Но, как видно из начала сообщения время уходит не столько на борьбу с С++, сколько на борьбу с ошибками проектирования и организации разработки.
Дык если есть более мощьный язык, то все становится проще. Нужно меньше программистов, проектирование становится ближе к коду. Объем исходников становится меньше. В итоге и бороться нужно с меньшим объемом проблем. Скажем, если на разработку игры на С++ нужно 10 программистов, то на Немерле возможно будет остаточно 4-ых. Это обязательно повысит эффктиность. К тому же проще делить код на крутой системынй и прикладной. Крутые программисты могут писать макросы и фрэймворки, а по слабее собирать из них готоые решения оторые в виду своей простоты будут иметь меньше ошибок и быстрее реализовываться.
E>На самом деле, идея попытаться переписать менее критичную по производительности часть проекта на C# когда-то была, но было не вполне понятно, как совместить управляемый код с неуправляемым, ну и времени, как обычно, не хватило.
На самом деле это не сложно. Но C# вам даст меньший выигрышь нежели Nemerle. Так что если убить некоторое время (возможно по вечерам) на его изучение, то глядишь следующий проект не будет делаться более двух лет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Вот только в чем? В красоте или в эффективности выполнения? BulatZiganshin утверждает что на хаскеле будет медленнее, хотя и более кратко и красиво.
Хаскель медленный язык. Медленный в силу своей специфики.
Для эффективности на уровне маш.команд конечно нужно понижать уровень, а не повышать. Только уверен, что ваши проблемы эффективности лежат не на уровне сочетания процессорных инструкций, а на уровне алгоритмов. Одно только автоматическое управление памятью упрощает применение многих алгоритмов и делает возможным то на что у вас не поднималась рука ранее. А уж в купе с другими возможностями, и говорить не о чем.
DC>Ммм. Возможно, мне трудно оценить их мощь.
У меня даже нет сомнений. Если конечно ты не лисп-хакер с десятилетним стажем.
DC>Но с алгоритмами они врядли способны что-то сделать, разве что упростят построение модели.
Они позволяют сделать возможным мечты.
Ты можешь относительно просто превраить интерпретакцию в компиляцию. Макарнонный код в краткий DSL. Сгенерировать код так как тебе надо, а не так как выходит.
DC>Насколько я понимаю эти макросы и есть основной конек Немерле.
Это вопрос мировозрения. Сейчас я уже так не считаю. Но макросы — это секретное оружие которое лисперы скрывали за грудой скобок много лет. И если бы не они, то небыло бы самого Немерле. Он в основном обязан себе и своим макросам. В нем даже большинство конструкций воде if/else или for реализованы макросами.
В общем, мое мнение, что и без мкросов С++ ему может составить конкуренцию только в простых задачах битовыжимания (что элементарно выносится в библиотеки). А с макросами он вообще недосягаем. Ведь это возможность заточить язык под свои задачи. Причем сделать это очевидным и доступным окружающим образом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alexmoon, Вы писали:
A>Сильное определение. Уверенность в себе — это конечно похвально. Но я бы как минимум заменил артикль это на возможно.
Это понятно. Ты ведь не видел того как может выглядеть метапрограммирование будь оно органично встроено в язык. Потому и сомневашся. А вот IT видел. Как сейчас помню восторженный его восклик в аске — "Оифигеть! Я добавил поле типа Location и забыл сделать его изменяемым, но компилятор мне сказал об этом! И это делает простой макрос!". Так что вы в разных условиях. Он видел и то, и то, а ты только шаблоны С++.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alexmoon, Вы писали:
A>Мог бы и это не сверхестественное умение. Просто в концепциях языка с точки зрения логики сие выглядело бы совершенно по другому, но если кому так не нравится, или кто то боится ошибится при реализации, тогда смотри выше мое предыдущее сообщение. Два раза одно и то же я не повторяю. Мы не дети. Давайте без нравится, а то я напишу что мне нравится Jennifer Lopes.
ОК, поясни что за концепция языка (гы-гы, тем кто использовал этот язык 10 лет к ряду), что не позволяет просто определить атрибуты? Может их просто нет в этом языке, а средства эмуляции настолько убоги, что не позволяют это сделать качественно? Я ошибаюсь? А тогда в чем же дело?
IT>>Ничего логичного и естетсвенного. Метапрограммирование на шаблонах — это высокоинтеллектуальное извращение. А извращение не может быть естественным. Даже высокоинтеллектуальное. A>Ничего общего с тем что вы определили не имеет. То что в вашем понимании извращение, может таковым совершенно не являтся, но в концепциях С# конечно такой гибкости нет, поэтому можно и таким аттрибутом по умолчанию наградить. Давайте озаглавливать контексты "Я так думаю", и наче обсуждение обречено.
В С# нет встроенного метапрограммирования. По этому и обсуждать не чего. А вот в Nemerle есть. И метапрограммирование на С++ на его фоне выглядит полнейшим извращением и убожеством.
Звучит громко? Но это правда. И чтобы ее осознать надо просто прочесть пару статей про макросы Немерле.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alexmoon, Вы писали:
A>Все нужно рассматривать в концепции языка.
Прблема в том, что у С++ очень куцие концепции. И рассматривая в них казалось бы простые и логичные решения оправдываются весьма уродливые решения.
A> Понятие "снег" не является generic. Ни один язык не вместит всех понятий на уровне встроенных типов.
Это не так. В хорошем языке на котором можно описывать лызные гонки, например, есть понятие "снег". И без него дейсвтительно глупо говорить о лыжных гонках. Представь всебе:
Бегун на плоских палках привязанных к ногам вырывается вперед...
Ужас, правда? Так вот хороший язык позволяет добавлять в него новые понятия. Применительно к ЯП такими возможностями являются библиотеки фукнций и классов, а так же метапрограммирование. То что можно добавить библиотекой (при приемлемо качестве) нет смысла реализовывать метапрограммой, но далеко не все можно сделать библиотекой. Вот тут и помогает матапрограммирование. Но оказываетс, что один язык предоставляет удобные и мощьные концеции для расширения себя любимого, в адругой один хитрый патцан научился использовать побочные эффекты от рекурсивного определения шаблонов, чтобы сэмулировать примитивнеший фукнциональный язык с убогим синтаксисом и плохой связью с компилятором. В итоге на одном языке можно творить чудеса, а на другом путем неимоверных по своему садизму изнасилований мозга получать примитивнийшие решения и радоваться этому как младенец.
A> Для меня необходимым и достаточным является то, что с максимальной гибкостью я могу определить любое из высокоуровневых понятий набором базовых.
Скорее с неимоверной убогостью. Но ты не поймешь этого пока будешь знать один С++, так как тут работает парадок Блаба
), и так и не дождался чтобы хоть кто-нибудь написал для сравнения их аналоги на своём языке
Приколист ты. Тут 90% Хаскеля вообще не знает. Еще 9% знает его в рамках прочтения введения. И еще 0.9% чуть глубже. А оставшиеся 0.1% или не заметила твое сообщение, или им просто влом этим заниматься. Тут пенисометрии был вагон и малая тележка. Поищи сам.
Скажу от себя, что почти любой язык с приличной поддержкой ФЯ и опциональной линивостью полвзоялет описать такие примеры не хуже. Поиск символа вообще смешон. В C#, например, это будет выглядить как str.Substring(80).LastIndexOf(' '), не говоря уже о ФЯ.
Так что проблемы тут бубут только у С++, так как на нем все надо воспринимать в его же концепциях (с).
BZ>чистый результат в моей работе — я написал архзиватор, по возможностям сравнимый я 7zip, но кодом в три раза меньше. подозреваю, что и время разработки было в три раза меньше, хотя это сложнее сравнить
Здорово. Жаль только что 7zip уже есть и он всех устраивает. А многих устраивает просто zip.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alexmoon, Вы писали:
A>Указатели есть базовое понятие с достаточной степенью свободы и насколько вы аккуратно проводите анализ составляющих, настолько мала вероятность вами ошибится.
Извини, ты смарт-поинтерами пользуешся?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В C#, например, это будет выглядить как str.Substring(80).LastIndexOf(' '), не говоря уже о ФЯ.
VD>Так что проблемы тут бубут только у С++, так как на нем все надо воспринимать в его же концепциях (с).
Да уж... Rocket science... То, что ты изобразил на C#, на C++ выглядит, мягко говоря, не сложнее: str.rfind(' ', 80)
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Alexmoon, Вы писали:
A>Нету. Представьте себе. Снег — это то что мы таковым назвали исходя из определенных характеристик свойственных такому состоянию среды.
Ну, начинается.
S>>Вот это утверждение хотелось бы как-то обосновать. Кто гибче — С или С++? А ведь С++ лаконичнее! A>Обосновывать это можно до бесконечности. Для этого как минимум должны быть взаимосогласованные определения. Их не было и не будет. Всех нас всегда будет что то не устраивать. Здесь нечего ответить, поскольку поставьте вопрос на абстракцию выше и вы поймете почему все от всего зависит и выиграть во всем абсолютно не возможно. Каждый выбирает обязательные критерии сам. Главное чтобы выбор был. Вы еще помните концепцию начала и в чем конечный вывод должен состоять?
Перечитал три раза, ничего не понял. Попробуй сосредоточиться и ответить на два вопроса: какой из языков гибче — С или С++? Какой из языков лаконичнее?
A>Некоторые вещи могут иметь конечно эквивалентный результат с совершенно различной архитектурой. Ну давайте уж порассуждаем о первостепенных происхождения. Я смотрю мы потихоньку сходим от осязаемого определения к блестанию умом на базе количества и гибкости оперируемых понятий.
Ну так не сходите. Поясняю: все эти "условно-одинаковые" подходы одинаковы только математически, при пренебрежении стоимостью разработки. На практике выигрывает та техника, которая позволяет сделать разработку дешевле. В основном за счет сокращения объема кода (в лексемах, естественно, а не в байтах) и автоматизации QA.
Нельзя отвлекаться от цели при анализе языков программирования. Все эти class, private, protected, namespace — они не сами по себе. Они только для того, чтобы сделать разработку дешевле.
A>>>
Sinclair notes:
A>>>Дело не в Дженнифер Лопес, а в совершенно объективных и измеримых характеристиках.
A>>>Что есть ИЗМЕРИМЫЕ а тем более ОБЪЕКТИВНЫЕ характеристики? S>>1. Компактность кода S>>2. Количество проверок, выполняемых компилятором
A>А может тогда уж не будем путать ОБЪЕКТИВНЫХ и СУБЪЕКТИВНЫХ характеристик. A>Количественные характеристики компактности и количества проверок, как оценочные характеристики, приведите пожалуйста.
Это обязательно? Сильна страсть к математике? Или неочевидно, что из этого компактнее:
obj->class->method(obj, 1);
obj->method(1);
? Или непонятно, вызов какой из функций будет лучше проверен компилятором:
add(a, b)
{
int a;
int b;
return a+b;
}
или
int add(a, b) { return a + b; }
A>>>Продолжая сопоставлять и анализировать все вышесказанное, попытайтесь ответить так, чтобы не положить ни на единого хотя бы участника общения. S>>Запросто. См. выше.
A>Отвечу на базе вашей же цитаты: A>
A>Вот и в программировании так же: некоторые вещи в принципе невозможно реализовать на более простой технологии, т.к. человеко-годы стремятся к бесконечности.
A>Запросто. Помимо человеко-лет есть набор составляющих уравнения, которые позволяют откатить человеки годы до вменяемой составляющей с учетом определенного уровня владения.
А можно то же самое по-русски? Ниче ведь не понятно: что такое "откатить"? Эаплатить откат? И что такое "вменяемая составляющая"? А что значит "учет определенного уровня владения"? Это что-то из бухгалтерии?
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
E>Идею, которые ты двигаешь в массы, я понял уже давно Но, как видно из начала сообщения время уходит не столько на борьбу с С++, сколько на борьбу с ошибками проектирования и организации разработки.
Угу хорошая идея начать коммерческую разработку на языке который все еще в бете (а судя по тому что недавно творилось в "Декларативном программировании" и как не смеялись некторые товарищи над багзилой другого языка в весьма глубокой).
Притом каких-то больших преимуществ в скорости разработки по сравнению с C++ + хороший скрипт (питон, луа) вы не получите.
Если рассматривать ситуацию Немерле vs (С++ + python) для тех же игр (правда я сейчас пишу только маленькие игры, но в больших тоже немного участвовал), то у Немерле по моему такие недостатки.
1) Язык не зарелизиен, до промышленного уровня ему как минимум еще несколько лет.
2) Язык (именно язык) вполне хорош для написания внутренностей ядра и тому подобного в игре, но написанное на на нем проигрывает C++ (притом сильно если будет использоватся mono) в производительности и расходе памяти. Для многих жадных по памяти и процессору алгоритмов проигрыш может быть фатальным.
3) Как язык для скриптов и вообще дизайнеров немерле слишком сложен, придется писать DSL, зная бардак с проектированием в игровых проектах 100% вы будете не один раз его переписывать, в общем лишняя работа обеспечена.
4) DSL будет на макросах, и так как скорее всего часто будет менятся и поэтому точно не будет предкомпилированным, и учитывая что в игру могут грузится много сотен скриптов получите хороший тормоз при перекомпиляции и загрузке этого счастья (что то порядка минут вместо секунд для скрипта).
5) Для С/C++ для разработки игр море как готовых библиотек так и просто всякого рода примеров обучалок и тому подобного. Конечно некторые из них можно скомпилировать и вызывать через интероп, но многие нет, так как цена вызова может быть дороговатой. Так что добавится работа по переписыванию с С++.
6) Платформа ограничена Windows и Xbox360. Есть mono для других платформ, но его производительности наверняка не хватит.
Здравствуйте, VladD2, Вы писали:
E>>Поэтому требования к скриптовому языку несколько другие: простота, читаемость и желательно какая-нибудь интерактивность, чтобы написанный скрипт можно был тут же и запустить. E>>В таких условиях написание скриптов на "взрослых" языках вроде C# или джавы или C++ выглядит как стрельба из пушки по воробьям.
VD>С++- конечно. А вот два других как раз более мем могут быть преспособлены для решения данной задачи. Ну, и конечно есть третий наличие которого делает бессысленым все три и скрипты в придачу.
Зачем их приспосабливать, если есть уже готовые решения? Только не надо повторять про мощность и безопасность этих языков. Они для этой задачи не то, чтобы совсем бесполезны, но неприоритетны. Нам нужно, чтобы человек, владеющий программированием на базовом уровне (т.е. надо знать, что такое переменные, ветвления, циклы и функции) писал небольшие, слабо связанные друг с другом программы.
Впрочем, я начал повторяться. Тут, парой сообщений выше, я уже написал, для чего по моему мнению нужны скрипты.
VD>>>Они локаничны, но совершенно не понятны. S>>Лаконичность нужно мерить не в символах, а в синтаксических элементах.
VD>Тоже не совсем прокатывает. Локоничность можно добиться введя уйму умолчаний. Ну, например, передавая контекс через глобальные переменные как в Руби. Только это плохая локонпчность.
интересная мысль. что если ясность можно измерить кол-вом концепций, которые человек должен помнить одномоментно?
тогда получится, что функциональный подход выигрывает потому, что вместо нескольких переменных, описывающих обработку, можно ввести одну функцию, которая её осуществляет, к примеру вместо x*a+b ввести функцию f = (+b).(*a) и дальше думать только об "f x"
ООП подход выигрывает потому, что вместо набора отдельных процедур, которые осуществоляют обработку данных независимо друг от друга, мы имеем дело с более общей единицей — объектом, и думаём о его поведении в целом
"обработка волной" в стиле unix и функциональных языков выигрывает потому, что мы каждый раз думаем только об одном промежуточном результате обработки, а не пытаемся рассматривать её глобально целиком. скажем, идиому "sort|uniq|sort" понять куда проще, чем императивную программу, выполняющую все эти действия за раз. юникс ведь потому и стал популярен, что позволил решать задачи обработки текста без создания сложных программ на С
BZ>>я лично предпочитаю писать скрипты на ruby. для сравнения пробовал haskell — некоторые вещи в нём проще (ну я тут уже приводил три примера ), некоторые — сложнее (императвиность), в целом вышло баш на баш. какой-нибудь императивный функциланльый интерпретируемый язык типа окамл был бы наверно идеалои для меня
VD>А зачем интерпретирвемый?
а зачем мне компилировать шелловские скрипты? скажем, у меня тестирование архиваторов таким скриптом управляется
VD>У ОКамла проблемы с черезмерной строгостью и статиченостью
в хаскеле это становится проблемой только при динамичсеколй передаче управлени (exceptions) и наверно ещё при динамичсекой подгрузке кода. в остальном строгость означает только что компилятор сам выведет все типы или скажет, что это совершенно невозможно. у меня было такое, когда я параметром функции ухитрился задать саму эту функцию, и компилятор сказал, что тип входит бесконечным
VD>Компонентность он поддерживает хуже чем С++.
почему это? в нём даже функторы есть, говорят мощнейшая штука
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eugene0, Вы писали: E>>Даже не знаю, что сказать. У нас эта цифра составит, наверное, процентов 10. VD>Извини, но мой опыт не позволяет мне с тобой согласиться. Да и доверия этому товарищу все же больше. Как ни как в Анрыл я играл чуть ли не 10 лет назад.
Насколько я помню, мои впечатления от первого анрыла в сравнении с аналогами тогда были: тормозной, неповоротливый движок. К тому же довольно часто падал.
E>> Утечки в начале были, но после того, как всем программистам объяснили, что такое смартпоинтер, об утечках тоже забыли и не вспоминают уже года два. VD>Вот она ключевая фраза — "уже года два"! То есть вы убили время еще тогда, и теперь еще 2 (!) года возитесь с проектом! А могли бы ВООБЩЕ не возиться с этими проблемами!
Ты ВООБЩЕ представляешь себе сроки разработки сколь либо серьезной игры?
VD>Вот вы и получаете 2 года разработки после того как какзалось бы всем все объяснили.
2 года на разработку игры — совершенно нормальный срок. Разумеется если это игра посложнее Zuma...
VD>К тому же 512 это сегодня. Игра которую начнут делать сегодня будет готова через год-два, а там глядишь и гиг будет стандартом.
Сегодня уже гиг...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, VladD2, Вы писали:
VD>Из ГУИ януса я делал только дерево.
Это то, которое при сворачивании иногда неправильно перерисовывается оставляя хвост?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
VD>>В C#, например, это будет выглядить как str.Substring(80).LastIndexOf(' '), не говоря уже о ФЯ.
ПК>Да уж... Rocket science... То, что ты изобразил на C#, на C++ выглядит, мягко говоря, не сложнее: str.rfind(' ', 80)
так это готовые, особенно твоё. дело-то именно в том, что хаскел предоставляет мощные средства КОМПОЗИЦИИ простых операций, в то время как для популярных языков существуют готовые бибилиотеки, где реализована куча алгоритмов. но выйди за пределы этих библиотек. наличие rfind ничем не поможет тебе в работе в lazy списками или деревьями. речь идёт именно о возможностях конструирования алгоритмов, предоставляемых языком
Здравствуйте, FR, Вы писали:
FR>Угу хорошая идея начать коммерческую разработку на языке который все еще в бете (а судя по тому что недавно творилось в "Декларативном программировании" и как не смеялись некторые товарищи над багзилой другого языка в весьма глубокой).
Если ты про nikov то это человек с очень редким талантом ломать вобще все. Онже запостил болие 1000 багов по решарперу, нашол кучу багов в C#...
А если он решит занятся D то рейтинг D по версии TIOBE взлетит выше крыши ибо багзила распухнит в разы.
FR>Притом каких-то больших преимуществ в скорости разработки по сравнению с C++ + хороший скрипт (питон, луа) вы не получите.
Громно ржу.
FR>Если рассматривать ситуацию Немерле vs (С++ + python) для тех же игр (правда я сейчас пишу только маленькие игры, но в больших тоже немного участвовал), то у Немерле по моему такие недостатки.
FR>1) Язык не зарелизиен, до промышленного уровня ему как минимум еще несколько лет.
Что-то мне подсказывает что он работает лучше чем D на который повесили это ярлык.
FR>2) Язык (именно язык) вполне хорош для написания внутренностей ядра и тому подобного в игре, но написанное на на нем проигрывает C++ (притом сильно если будет использоватся mono) в производительности и расходе памяти. Для многих жадных по памяти и процессору алгоритмов проигрыш может быть фатальным.
А именно?
Есть проблемы (уверен временные) с перемножением кучи векторов на матрицу и тп. Из за того что .НЕТ не использует всякие там SSE.
Но это можно и интеропнуть ибо один вызов обрабатыват сразу кучу всего.
FR>3) Как язык для скриптов и вообще дизайнеров немерле слишком сложен, придется писать DSL, зная бардак с проектированием в игровых проектах 100% вы будете не один раз его переписывать, в общем лишняя работа обеспечена.
Бардак в игровой индустрии исключительно по тому что недальновидные боссы игродельчиских контор плохо относятся к работникам и по этому в игродельческой индустрии никто кроме фанатиков надолго не задерживается.
FR>4) DSL будет на макросах, и так как скорее всего часто будет менятся и поэтому точно не будет предкомпилированным, и учитывая что в игру могут грузится много сотен скриптов получите хороший тормоз при перекомпиляции и загрузке этого счастья (что то порядка минут вместо секунд для скрипта).
Даже если DSL будет менятся раз в день что бред... достаточно будет один раз скомпилить сборку с макросами. Да один раз в день. А не каждый раз.
FR>5) Для С/C++ для разработки игр море как готовых библиотек так и просто всякого рода примеров обучалок и тому подобного. Конечно некторые из них можно скомпилировать и вызывать через интероп, но многие нет, так как цена вызова может быть дороговатой. Так что добавится работа по переписыванию с С++.
Угу... видил я эти поделки... в гробу и белых тапочках...
FR>6) Платформа ограничена Windows и Xbox360. Есть mono для других платформ, но его производительности наверняка не хватит.
Ну десктоп кроме винды рассматривать вобще не имеет смысла.
А на приставочном рынке Xbox360 не маленький сегмент.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, BulatZiganshin, Вы писали:
BZ>чистый результат в моей работе — я написал архзиватор, по возможностям сравнимый я 7zip, но кодом в три раза меньше. подозреваю, что и время разработки было в три раза меньше, хотя это сложнее сравнить
Когда можно будет посмотреть его результаты здесь: http://www.maximumcompression.com ?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, VladD2, Вы писали:
VD>>>>>Второе покоеление уже писалось с использованием скриптов и С++. DC>>>>Использование скриптов ИМХО еще позже появилось. VD>>>Погляди Анрэл 1. CC>>Quake 1 — QuakeC — компилируемый язык с VM. VD>Кармак все еще и на С пишет. Это не показаоель. Показатель скорее то, что он просрал очередной виток технологий ФарКику. Без комментариев!!!
DC>>>> Где 3Д библиотеки для Немерле/ОКамл/... которые удовлетворяют разработчиков движков? VD>>>Они прекрасно исползуют имеющиеся бибилотеки. Для Немерле будет радным XNA, от МС CC>>Ой только не надо про %НЮ. Потому как кроме как нецензурно о этой поделке отозваться не могу... Шшупали... VD>А кто ты такой чтобы твое мнение по этому поводу было интересно?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, VladD2, Вы писали:
VD>С++- конечно. А вот два других как раз более мем могут быть преспособлены для решения данной задачи. Ну, и конечно есть третий наличие которого делает бессысленым все три и скрипты в придачу.
Хм, а на этом "убийце скриптов" можно не перезапускать основную программу после изменения отдельного маленького компонента, а просто указать, что если "скриптик" Х изменился после последней его загрузки — загрузить его заново? И что для этого понадобится включить в эту программу — весь framework языка или маленькую dll-ку интерпретатора?
Только не надо говорить про кривость дизайна. Просто скажите — есть такая возможность или нет?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eugene0, Вы писали:
E>>Утечки в начале были, но после того, как всем программистам объяснили, что такое смартпоинтер, об утечках тоже забыли и не вспоминают уже года два.
IT>Вот это меня всегда особенно забавляло. С одной стороны адресная арифметика представляется нам как одно из фундаментальных средств, позволяющих использовать плюсы как язык для написания эффективных программ. С другой, абсолютно все вменяемые девелоперы, с которыми я когда либо общался, душат голые указатели на корню с помощью всевозможных костылей в виде смарт-поинтеров.
IT>Где логика я вас спрашиваю?
Логики здесь нет по нескольким совершенно прозрачным причинам.
С одной стороны адресная арифметика представляется нам как одно из фундаментальных средств, позволяющих использовать плюсы как язык для написания эффективных программ.
Совершенно верно, но чем большую свободу представляет средство, тем больше внимания оно требует при использовании. Здесь природная человеческая небрежность очень сильно проявляется. Отчасти здесь все компенсируется тем, что на определенном уровне ты начинаешь немного по другому подходить к решению тех или иных проблем. Вариантов несколько. Ты агрегируешь указатель и сразу же инициализируешь его в конструкторе. Тут же определяешь его область видимости и проверяешь его на границе области, ежели конечно он является управляющим для ресурса, на который он указывает. Если человек этого не воспринимает, по разным причинам, значит он должен понимать какую степень риска утечки ресурсов ему несет та или иная фитча. Все как в жизни. Чем более грозное оружие ты даешь человеку в руки, тем больший соблазн у него использовать это не по назначению и тем большая моральная подготовка должна быть у человека использующего. Не используй никогда то, чего боишся или не знаешь, и что не передернув ствол, даже при вытащенном магазине нельзя нажимать курок.
С другой, абсолютно все вменяемые девелоперы, с которыми я когда либо общался, душат голые указатели на корню с помощью всевозможных костылей в виде смарт-поинтеров.
Таким девелоперам опасно пользоваться и смарт-поинтерами, поскольку по всем известным причинам они не абсолютная панацея и человек не знающий их узких еще с большими проблемами столкнется при поиске причин падений.
И еще раз повторюсь. То что не интересно вникать в некоторые фитчи столь гибких реализаций, абсолютно не обозначает что их нужно душить на корню.
Я смарт-поинтерами пользуюсь по одной простой причине, когда область видимости ограничена внутренней реализацией агрегируеющего и мне не зачем в деструкторе делать лишнюю запись. Ежели я отдаю его в свободное плавание, то и оболочки я делаю под соответствующий уровень определения.
То что у нас есть естественное стремление пенести свои недостатки на плечи других — это не значит что мы должны своим авторитетом давить на сознания тех, кто еще находится в состоянии выбора. Когда придет время, они сами зададут вам вопрос куда идти дальше.
Вы можете рассказывать все что угодно, но если вы говорите о вещах мне очевидных то ваше стремеление прицепить меня к другому выводу имеет нулевой КПД.
Используйте пожалуйста только термины "Я ТАК ДУМАЮ" а не "КОМИТЕТ ДАВНО ПОРА ОТДАТЬ ПОД СУД". Если вам скажу, что он все делает правильно исходя из определяющих условий, то наш спор не закончится до конца жизни и так и умрем не познав истинного удовольствия.
P.S. И пожалуйста хотя бы из уважения к собеседнику не ищите ошибок в моих выражениях как факт, потому что я писал бегущую мысль и если что то не главное было упущено, это не обозначает что это осталось за пределами моего внимания. Это всего лишь не касается обсуждаемой темы.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, FR, Вы писали:
FR>>Угу хорошая идея начать коммерческую разработку на языке который все еще в бете (а судя по тому что недавно творилось в "Декларативном программировании" и как не смеялись некторые товарищи над багзилой другого языка в весьма глубокой). WH>Если ты про nikov то это человек с очень редким талантом ломать вобще все. Онже запостил болие 1000 багов по решарперу, нашол кучу багов в C#... WH>А если он решит занятся D то рейтинг D по версии TIOBE взлетит выше крыши ибо багзила распухнит в разы.
Надо его попросить.
FR>>Притом каких-то больших преимуществ в скорости разработки по сравнению с C++ + хороший скрипт (питон, луа) вы не получите. WH>Громно ржу.
Зря.
FR>>Если рассматривать ситуацию Немерле vs (С++ + python) для тех же игр (правда я сейчас пишу только маленькие игры, но в больших тоже немного участвовал), то у Немерле по моему такие недостатки.
FR>>1) Язык не зарелизиен, до промышленного уровня ему как минимум еще несколько лет. WH>Что-то мне подсказывает что он работает лучше чем D на который повесили это ярлык.
По устойчивости скорее близки. D тяжелей довести до ICE чем промышленные C++ компиляторы. Nemerle достаточно уcтойчив, но когда я с ним возился я и его (также как и D) доводил до ICE.
D на самом деле рановато присвоили 1.0, хотя с другой стороны сколько уже можно
FR>>2) Язык (именно язык) вполне хорош для написания внутренностей ядра и тому подобного в игре, но написанное на на нем проигрывает C++ (притом сильно если будет использоватся mono) в производительности и расходе памяти. Для многих жадных по памяти и процессору алгоритмов проигрыш может быть фатальным. WH>А именно? WH>Есть проблемы (уверен временные) с перемножением кучи векторов на матрицу и тп. Из за того что .НЕТ не использует всякие там SSE. WH>Но это можно и интеропнуть ибо один вызов обрабатыват сразу кучу всего.
Проблемы может и временные, но работать то нужно здесь и сейчас.
FR>>3) Как язык для скриптов и вообще дизайнеров немерле слишком сложен, придется писать DSL, зная бардак с проектированием в игровых проектах 100% вы будете не один раз его переписывать, в общем лишняя работа обеспечена. WH>Бардак в игровой индустрии исключительно по тому что недальновидные боссы игродельчиских контор плохо относятся к работникам и по этому в игродельческой индустрии никто кроме фанатиков надолго не задерживается.
Угу. И платят плохо.
FR>>4) DSL будет на макросах, и так как скорее всего часто будет менятся и поэтому точно не будет предкомпилированным, и учитывая что в игру могут грузится много сотен скриптов получите хороший тормоз при перекомпиляции и загрузке этого счастья (что то порядка минут вместо секунд для скрипта). WH>Даже если DSL будет менятся раз в день что бред... достаточно будет один раз скомпилить сборку с макросами. Да один раз в день. А не каждый раз.
Все равно даже предкомпилированная будет заметно медленее скриптов.
FR>>5) Для С/C++ для разработки игр море как готовых библиотек так и просто всякого рода примеров обучалок и тому подобного. Конечно некторые из них можно скомпилировать и вызывать через интероп, но многие нет, так как цена вызова может быть дороговатой. Так что добавится работа по переписыванию с С++. WH>Угу... видил я эти поделки... в гробу и белых тапочках...
Ну конечно мы пишем все сами и всегда наш код лучше чужого
FR>>6) Платформа ограничена Windows и Xbox360. Есть mono для других платформ, но его производительности наверняка не хватит. WH>Ну десктоп кроме винды рассматривать вобще не имеет смысла.
Мак очень даже имеет смысл, хотя для больших игр как не знаю, для маленьких очень приличный процент.
WH>А на приставочном рынке Xbox360 не маленький сегмент.
E>Вы меня, конечно, извините, но в ваших словах мне так и слышится бравада: "Я освоил Хаскел! Я проперся от него! Я познал неведомое доселе!". И вспоминается мне один очень талантливый мужик, фанат Пролога, который несколько лет назад написал на Прологе офигенную систему. В которой никто не мог разобраться кроме него. Более того, когда однажды потребовалось выяснить причину ее странного поведения в какой-то ситуации, на вопрос "А как она вообще работает" он ответил -- "А хрен его знает". И закончилось все, как и можно было ожидать, тем, что после его ухода все творение было в довольно короткий срок переписано на C++ парой вчерашних студентов. И работало затем несколько лет без нареканий. Причем те студенты сейчас ведут еще более серьезные проекты и слова Хаскел, я думаю, даже не слышали.
когда я в первый раз работал за деньги, мне поручили написать одну интерактивную программу с системой меню. я сам сделал соответствующую библиотечку. было это на С, и для уменьшения размера кода я очень активно использовал препорцессор. в конце концов система подстановок в подстановки стала настолько запутанной, что я перестал в ней разбираться
в общем, на таких ошибках учатся. я с тех пор никогда больше не перегружал препроцессор. и мой 15-летний опыт коммерческой разработки, вот таких вот удачных и неудачных решений, отлажки, копирования кода, выписания шаблонных конструкций языка, позволил выработать определённые идеи о том, как нужно программировать и что для этого от ЯП нужно. языков я изучал множество — от APL до Явы, так что могу сравнивать
где-то в 60-70-х годах Дейкста написал книжку "взаимодействующие последовательные процессы", в которой ищлагался подход к написания параллельных и распределённых порграмм, не требующий явного описания семафоров, рандеву, мониторов и тому подобных низкоуцровневых вещей. в упрощённом виде его концепция используется в юниксовских пайпах. аналогичным образом устроена и моя программа — она состоит из 4 тредов, передающих информацию друг другу:
в свою очередь, compress разделяется ещё на несколько тредов, последовательно сжимающих данные. разве это не красиво? и позволило мне это реализовать именно наличие higher-order funcs. я думаю о своей программе не в плане отдельных значений которые нужно обработать, а в плане алгоритмов, из которых конструируются более сложные алгоритмы, при этом средства их конструирования также являются алгоритмами. вот это и есть метаподход к программированию на уровне хаскела
при этом одновременно я пишу и на C, так что могу сравнивать получается так, что я сначала продумываю алгоритм на уровне того, как он должен обрабатывать данные, а затем сажусь и выписываю все те циклы и присваивания, которые до этого придётся выполнить. так что могу сказать и чем знание хаскела помогаетв низкоуровневом программировании — чётче декомпозиция задачи, возникает предлстваление о ней как о наборе отдельных процессов преобразования данных с ясно определённым входом и выходом
VD>>К тому же 512 это сегодня. Игра которую начнут делать сегодня будет готова через год-два, а там глядишь и гиг будет стандартом. CC>Сегодня уже гиг...
у меня знакомый весной купил машину с гигом. осенью его спрашивают, он говорит — у меня два гига. думаю, дело в том, что у него осталось смутное впечатление "у меня памяти ого-го сколько!", а по осени гиг за ого-го уже не канал
BZ>>чистый результат в моей работе — я написал архзиватор, по возможностям сравнимый я 7zip, но кодом в три раза меньше. подозреваю, что и время разработки было в три раза меньше, хотя это сложнее сравнить CC>Когда можно будет посмотреть его результаты здесь: http://www.maximumcompression.com ?
боюсь, что нескоро. не потому, что архиватор плохой, а потому, что интерес чисто спортивный и меня вполне удовлетворяет своё собственное осознание крутизны
Здравствуйте, VladD2, Вы писали:
VD>ОК, поясни что за концепция языка (гы-гы, тем кто использовал этот язык 10 лет к ряду), что не позволяет просто определить атрибуты?
И за одно тому кто владеет метаизвращениями на шаблонах в совершенстве.
VD>Звучит громко? Но это правда. И чтобы ее осознать надо просто прочесть пару статей про макросы Немерле.
А лучше самому попробовать.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Еще раз извините, если мое сообщение задело вас. Надеюсь, что здесь мне получится объяснить свою мысль лучше.
BZ>когда я в первый раз работал за деньги, мне поручили написать одну интерактивную программу с системой меню. я сам сделал соответствующую библиотечку. было это на С, и для уменьшения размера кода я очень активно использовал препорцессор. в конце концов система подстановок в подстановки стала настолько запутанной, что я перестал в ней разбираться
Таких историй большинство участников форума могут привести множество. Это нормальный процесс обучения.
BZ>где-то в 60-70-х годах Дейкста написал книжку "взаимодействующие последовательные процессы", в которой ищлагался подход к написания параллельных и распределённых порграмм, не требующий явного описания семафоров, рандеву, мониторов и тому подобных низкоуцровневых вещей. в упрощённом виде его концепция используется в юниксовских пайпах. аналогичным образом устроена и моя программа — она состоит из 4 тредов, передающих информацию друг другу:
BZ>create_archive_structure | read_input_files | compress | write_to_archive
BZ>в свою очередь, compress разделяется ещё на несколько тредов, последовательно сжимающих данные. разве это не красиво? и позволило мне это реализовать именно наличие higher-order funcs. я думаю о своей программе не в плане отдельных значений которые нужно обработать, а в плане алгоритмов, из которых конструируются более сложные алгоритмы, при этом средства их конструирования также являются алгоритмами. вот это и есть метаподход к программированию на уровне хаскела
И это все правильно и замечательно. Но, есть две вещи:
* вы заостряете внимание на Хаскел. Чтож он вам нравится, он соответствуют вашим представлениям о том, как нужно программировать. Хотя на мой взгляд, попытки сравнения Хаскеля с другими языками в данном треде выглядят как "Круче Хаскел только яйца!". Показалось мне так. Обычное, думаю, дело -- один написал с одними мыслями, другой прочитал с другими мыслями;
* мое личное отношение к сложным вещам. Я здесь уже говорил об этом, зарабатывал кучу минусов, наживал обвинения в посредственности, но остался при своем. У людей разные способности, в том числе и по освоению/использованию сложных инструментов. Мне доводилось наблюдать это во время учебы на примерах изучения высшей математики (мат.анализ, в котором мало кто в нашей группе разбирался и еще меньшее количество людей могло применять полученные знания для решения практических задач) и Пролога (большинство вообще, представте, вообще не понимало, в чем дело). При том, есть небольшое количество индивидумов которым природой и воспитанием дадено воспринимать вещи по другому. Кто-то воспринимает математику как само собой разумеющееся, кто-то так же относится к программированию. Вот у меня, например, с программированием вообще никогда не было проблем, в том числе и с Прологом. В отличии от математики. Так вот, в программировании разные способности индивидумов так же проявляются. Кто-то хорошо программирует на Java, но плохо на C++, кто-то замечательно знает Пролог и может на нем сделать все, что угодно, а другой вообще не может понять, по каким правилам Прологовские программы работают. А раз у людей разные способности и пристрастия, то при некоторых условиях с этим приходится считаться. Например, при передаче чужого кода на сопровождение. При попытке заменить выбывшего по объективным причинам или форс-мажорным обстоятельствам человека. И здесь оказывается, что заменить Java программиста возможно. C++ программиста, в принципе, возможно. Найти адекватную замену Хаскел или Пролог программисту... Это мало реально еще и потому, что, по моим наблюдениям, те же Пролог программисты имеют очень высокий уровень, это не обычные кодеры, которым по жизни хватает один раз выученного языка и одной освоенной IDE, и работы над одинаковыми проектами. А значит, Хаскел и Пролог программисты подходят к своей работе более творчески и применяют неординарные идеи. Соответственно, удачно заменить их сможет только такой же продвинутый и неординарный человек. Так что остается всего ничего -- найти его. Ну или переписать все так, чтобы в дальнейшем ротация коллектива не была проблеммой.
А посему получается, что если вы делаете что-нибудь самостоятельно или в очень небольшой группе таких же как вы людей, то что Хаскел, что Пролог, что еще что-нибудь экзотическое -- нет разницы. Совсем другое дело -- дальнейшая судьба написанного вами кода, который вы по каким-то причинам, больше не можете сопровождать. Вот как раз мейнстримовые языки (даже такие ругаемые и проигрывающие конкурентам, как C и C++) имет здесь гораздо больший запас прочности. И большая многословность и даже проигрыше в функциональности у разработанных на мейнстримовых языках систем компенсируются вот этим вот запасом прочности.
Чтобы проилюстрировать эту мысль я и привел пример из собственного опыта.
Вот как-то так. Надеюсь, что врага я себе не нажил.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>>>чистый результат в моей работе — я написал архзиватор, по возможностям сравнимый я 7zip, но кодом в три раза меньше. подозреваю, что и время разработки было в три раза меньше, хотя это сложнее сравнить CC>>Когда можно будет посмотреть его результаты здесь: http://www.maximumcompression.com ? BZ>боюсь, что нескоро. не потому, что архиватор плохой
Ну, закинул бы все равно — просто для сравнения эффективности алгоритмов. Все равно для практического применения из их списка архиваторов пригодно процентов 20-30%. Остальные такие же спортивные эксперименты...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, BulatZiganshin, Вы писали:
VD>>>К тому же 512 это сегодня. Игра которую начнут делать сегодня будет готова через год-два, а там глядишь и гиг будет стандартом. CC>>Сегодня уже гиг...
BZ>у меня знакомый весной купил машину с гигом. осенью его спрашивают, он говорит — у меня два гига. думаю, дело в том, что у него осталось смутное впечатление "у меня памяти ого-го сколько!", а по осени гиг за ого-го уже не канал
Для PC это конечно так, но для тех же игровых приставок время жизни которых 5 — 7 лет, все гораздо печальнее, есть сейчас 512 Mb (притом общей и для видео и для приложении) памяти (или в другом случае 256 под приложения и 256 под видео) и больше в ближайшие годы точно не будет.
VD>>ОК, поясни что за концепция языка (гы-гы, тем кто использовал этот язык 10 лет к ряду), что не позволяет просто определить атрибуты? WH>И за одно тому кто владеет метаизвращениями на шаблонах в совершенстве.
VD>>Звучит громко? Но это правда. И чтобы ее осознать надо просто прочесть пару статей про макросы Немерле. WH>А лучше самому попробовать.
знаете, у меня из богатого опыта отношение к метапрограммированию умеренное — с однйо стороны, конечно, хорошо, что язык можно расширять, не дожидаясь автором компиляторов и комитетчиков. с другой стороны, поддержка возможностей языка — это не только компиляция. а сообщения об ошибках? а отладка? а понимание того, как эта хреновина вообще работает? а взаимодейтсиве с системой типов? те же шаблоны в С++ появились как раз как замена макросов препроцессора — очень уж неудобно с ними было
Здравствуйте, BulatZiganshin, Вы писали:
BZ>знаете, у меня из богатого опыта отношение к метапрограммированию умеренное — с однйо стороны, конечно, хорошо, что язык можно расширять, не дожидаясь автором компиляторов и комитетчиков. с другой стороны, поддержка возможностей языка — это не только компиляция. BZ>а сообщения об ошибках?
Как родные. Болие того многие конструкции языка сделаны именно макросами. BZ>а отладка?
Также как и обычных программ. Поднимаешь компилятор под отладчиком, ставишь брейкпоинт в макросе и вперед. BZ>а понимание того, как эта хреновина вообще работает?
В смысле? Скажем интеграция в студию показывает во что разворачивается макрос. BZ>а взаимодейтсиве с системой типов?
Никаких проблем. BZ>те же шаблоны в С++ появились как раз как замена макросов препроцессора — очень уж неудобно с ними было
Насчет препроцессора С согласен на 100%.
Но макросы немерла это совсем другая история.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Last Cjow Rhrr, Вы писали:
LCR>Оператор "euro" из Understanding monads
В Математике удобнее было
там запись a[b[c[d[x]]]] (квадратные скобки там значат то же, что и круглые в С — вызов функции с аргументом в скобках)
можно было выразить так:
a[b[c[d @ x]]]
или так:
a @ b @ c @ d @ x
или так:
x // d // c // b // a
или так:
c @ d[x] // b // a
ну и т.д. (пробелы необязательны)
при этом для бинарных функций был еще такой сахар:
f[b,c]
можно писать как
b ~ f ~ c
BZ>>когда я в первый раз работал за деньги, мне поручили написать одну интерактивную программу с системой меню. я сам сделал соответствующую библиотечку. было это на С, и для уменьшения размера кода я очень активно использовал препорцессор. в конце концов система подстановок в подстановки стала настолько запутанной, что я перестал в ней разбираться
E>Таких историй большинство участников форума могут привести множество. Это нормальный процесс обучения.
я тебя просто неправильно понял. что касается Пролога — то суть декларативного программирования в том и состоит, что программист описывает не шаги решения задачи, а результат, который он хочет получить. и логическое программирование — наиболее декларативное. может, он это и имел в виду?
E>* вы заостряете внимание на Хаскел. Чтож он вам нравится, он соответствуют вашим представлениям о том, как нужно программировать. Хотя на мой взгляд, попытки сравнения Хаскеля с другими языками в данном треде выглядят как "Круче Хаскел только яйца!". Показалось мне так. Обычное, думаю, дело -- один написал с одними мыслями, другой прочитал с другими мыслями;
ну это, я думаю, нет смысла комментировать. хотя нет — я старался писать о преимуществах higher-order funcs, immutable objects, lazy evaluation, type inference и других средств хаскела. когда речь идёт о скорости — я писал о C++. когда о создании скриптов — это будет, скажем, руби. если я чего-то не знаю — я так об этом и говорю. по возможностям, необходжимым для промышленного программирования, хаскел — это лучший язык из тех, что я знаю. но не потому, что это хаскел. а потому, что в нём есть такие-то и такие-то возможности. вот на уровень возмоджностей языка мне и хотелось бы перевести эту дискуссию, а не устраивать здесь свяященные войны. я например вполне поддерживаю Влада в том, что Немерле быстрее хаскела, и в свою очередь языки с нативной компиляцией вероятно быстрее байткодовых
E>* мое личное отношение к сложным вещам. Я здесь уже говорил об этом, зарабатывал кучу минусов, наживал обвинения в посредственности, но остался при своем. У людей разные способности, в том числе и по освоению/использованию сложных инструментов. Мне доводилось наблюдать это во время учебы на примерах изучения высшей математики (мат.анализ, в котором мало кто в нашей группе разбирался и еще меньшее количество людей могло применять полученные знания для решения практических задач) и Пролога (большинство вообще, представте, вообще не понимало, в чем дело). При том, есть небольшое количество индивидумов которым природой и воспитанием дадено воспринимать вещи по другому. Кто-то воспринимает математику как само собой разумеющееся, кто-то так же относится к программированию. Вот у меня, например, с программированием вообще никогда не было проблем, в том числе и с Прологом. В отличии от математики. Так вот, в программировании разные способности индивидумов так же проявляются. Кто-то хорошо программирует на Java, но плохо на C++, кто-то замечательно знает Пролог и может на нем сделать все, что угодно, а другой вообще не может понять, по каким правилам Прологовские программы работают. А раз у людей разные способности и пристрастия, то при некоторых условиях с этим приходится считаться. Например, при передаче чужого кода на сопровождение. При попытке заменить выбывшего по объективным причинам или форс-мажорным обстоятельствам человека. И здесь оказывается, что заменить Java программиста возможно. C++ программиста, в принципе, возможно. Найти адекватную замену Хаскел или Пролог программисту... Это мало реально еще и потому, что, по моим наблюдениям, те же Пролог программисты имеют очень высокий уровень, это не обычные кодеры, которым по жизни хватает один раз выученного языка и одной освоенной IDE, и работы над одинаковыми проектами. А значит, Хаскел и Пролог программисты подходят к своей работе более творчески и применяют неординарные идеи. Соответственно, удачно заменить их сможет только такой же продвинутый и неординарный человек. Так что остается всего ничего -- найти его. Ну или переписать все так, чтобы в дальнейшем ротация коллектива не была проблеммой.
вопрос "если наш язык так крут, почему же его никто не использует?" в сообществах small языков возникают куда чаще, чем здесь есть даже статья об этом профессора Вадлера, одного из авторов Haskell и generic Java. если кратко, то дело (помимо объективных свойств самого языка) в *инфораструктуре*: библиотеках, средствах разработки, книгах, обучении и в конечном счёте подготовленных специалистах
спецы по Прологу или Немерлу — хорошие программисты не потому, что язык хорош. я вот скажем пишу на хаскеле, си и delphi, так что — мои способности каждый день меняются? дело в том, что для изучения скажем ООП+ООД уже есть хорошо накатанная колея, этому учат с института и человек думает о программе в этих терминах на автомате, воспринимает их как нечто соверщшенно ращзумеющееся — точно так же, как умение говорить. как мне Влад говорил, "на самом деле мир — императивен"
людей, способных изучить и эффективно применять какой-нибудь язык, для которого нет хорошо накатанных паттернов, тем более для которого нет отладчиков, библиотек и т.д. — мало и в любом случае они работают неэффективно. так что мой совет — не использовать, а джержать нос по ветру. и не думать, что лучше, чем в C++ ничего уже не сделаешь. как я уже говорил, функциональное мышление мне лично помогает лучше струтурировать сишные программы
E>А посему получается, что если вы делаете что-нибудь самостоятельно или в очень небольшой группе таких же как вы людей, то что Хаскел, что Пролог, что еще что-нибудь экзотическое -- нет разницы. Совсем другое дело -- дальнейшая судьба написанного вами кода, который вы по каким-то причинам, больше не можете сопровождать. Вот как раз мейнстримовые языки (даже такие ругаемые и проигрывающие конкурентам, как C и C++) имет здесь гораздо больший запас прочности. И большая многословность и даже проигрыше в функциональности у разработанных на мейнстримовых языках систем компенсируются вот этим вот запасом прочности.
я вас и не призываю на него перейти. вы меня наверно с кем-то перепутали
С другой, абсолютно все вменяемые девелоперы, с которыми я когда либо общался, душат голые указатели на корню с помощью всевозможных костылей в виде смарт-поинтеров.
A>Таким девелоперам опасно пользоваться и смарт-поинтерами, поскольку по всем известным причинам они не абсолютная панацея и человек не знающий их узких еще с большими проблемами столкнется при поиске причин падений.
Когда нечего сказать, начинают рассказывать про кривость рук
CC>Ну, закинул бы все равно — просто для сравнения эффективности алгоритмов. Все равно для практического применения из их списка архиваторов пригодно процентов 20-30%. Остальные такие же спортивные эксперименты...
значит, даю справку по арзиваторам. на данный момент самый лучший практический архиватор — 7zip 4.43, причём именно этой версии — Игорь в прошлом году заметно рванул вперёд и теперь существенно обходит uharc.
далее. написать алгоритм вроде lzma (из 7-zip) самому — это несколько лет работы. я этого делать и не собирался
однако тем не менее сделать архиватор, который будет жать лучше, чем 7-zip, труда не составляет. достаточно взять lzma (доступный в исходниках), прикрутить к нему ppmd для текстовых файлов, добавить несколько препроцессоров — и комплексный обед готов. в моей программе испольщзуется штук 8 алгоритмов сджатия, причём я сам написал только два из них, довольно мелких. поэтому нет ничего удивительного в том, что программа сжимает лучше и быстрее оригинала, на котором она базируется. специалисту для того, чтобы понять, как она будет сжимать, достаточно прочесть список использованных алгоритмов — ну знаете, как в этом анекдоте "- анекдот 885! — все смеются, один не смеётся"
над вопросами практического применения я сейсчас потихоньку и работаю. надёжность, фичи, расширяемость формата архива
Вот здесь я уже вижу более конструктивное обсуждение. И чем дальше это все обсуждение заходит, тем более прозрачно выражается конструкция того, что у разных языков различное плавание и чем больше выбор, и тем большему количеству специалистов наши знания могут быть нужны и доступны. Если я что то пропустил — это значит лишь то, что я за эти мысли уже поставил вам +1, либо оно было сопровождающим и не требующим ответа комплиментом. Давайте будем не перегружать обсуждение не главным.
BZ>можно считать, что я пошёл ещё дальше и весь прикладной код пишу на хаскеле, а низкоуровневый — на C++ и не требую ни от того, ни от другого языка неестественных для него трюков. что касается арзитектурного подхода, то я тоже когда-то отладивал C с помощью printf'ов. можно чему угодно обезьяну научить но всё же лучше потратить силы на то, чтобы научиться писать более сложные программы с современными языками, нежели учиться делать несложные вещи, которые становятся сложными из-за устаревшего инструментария
Чуть-чуть лишь поправлю. И я так делаю. Я backend пишу только на С++ и не плачу о том что меня никто не защищает от моих ошибок, а лишь считаю за должное знать то, как минимум чем пользуюсь. А frontend вообще пишу без ограничения в выборе а на всем что БОЛЕЕ ВСЕГО подходит для реализации данной части. И здесь никаких моральных заблуждений и ограничений в выборе исходя из допустимых критериев хоть скорости разработки, хоть переносимости, хоть эффективности. Все хорошо в меру и это единственное утверждение.
но всё же лучше потратить силы на то, чтобы научиться писать более сложные программы с современными языками, нежели учиться делать несложные вещи, которые становятся сложными из-за устаревшего инструментария
с этим вообще никто не спорит и считаю глупостью опровергать утверждение. Просто из-за собственных предпочтений те или иные люди и выбирает приоритетные области для себя. И на этом все. Все остальное действительно БРОВАДА, не меньше и не больше.
Я бы вообще в обсуждение не вступал бы, если бы не стали ошибочно определять слово "ЗАМЕНА" в контексте "ДОПОЛНЕНИЕ".
А то начали с того, что С++ вообще ущербен и дошли до того что комитет калдет куда то не туда, где ожидалось. Это все бред ..... Все идет по заранее намеченному плану и не пытайтесь опровергнуть то что совершенно очевидно. Чем на более высоком уровне развития мы находимся, тем более разнообразный инструмент мы используем. Не знание инструмента не освобождает от отвественности за его использование. И все. Остановились на этом.
BZ>вы в 80-е программировали? да ещё и отслеживали все события в мире компилтяоров?? я-то просто недавно надыбал dr dobbs за эти годы и с удовольствием отследил борьбу и языков, и компиляторов. кол-во компиляторов C, паскаля и модулы было тогда практически одинаковым — 5 модул, шутк 6-7 Си. ну и ещё интерсено вспомнить, что С++ пошёл только потому, что разработчики были уверены, что на нём можно будет писать программы не медленней, чем на C
Программированием я начал увлекаться начиная с 88, поэтому очевидно, что вся история мне стала интересна и доступна позднее. Отсюда и отказ от необходимости дальнейшего цитирования истории. Я надеюсь что буквально воспринимать сопровождающие цитаты не стоит буквально. Давайте сокращать количество тезисов, а то и сами утонем.
BZ>давайте это по-другому выразим. спец C++ , по-вашему — это человек, который в несколько раз дольше учился, в несколько раз больше работает, и в конечном счёте получает ровно то же, что и спец в более современно языке? "товарищ сержант, ну можно я веником подмету?"
Не совсем так и я думаю вы со мной согласитесь.
спец по С++ — это то что вы определили, только получает он возможностей, если он в меру вменяем конечно, в разы больше чем спец. на более современном языке. "Разы больше" обозначает лишь то, что никогда и ни один язык не будет максимально эффективен абсолютно во всех областях и на всех уровнях мышления, хоть какие бы возможности он не предоставлял. Меня во всем этом радует только одно, что вы наконец то нашли для себя то, что искали и это главное.
Последнюю шутку в кавычках я запомню как анекдот
Чем больше тезис и чем большее количество конечных определений затронуто, тем дальше вы от истины. Но даже при соблюдении всех условий, вы никогда не будете стоять на ее пороге. Идиома о уникальности взглядов и мышлений.
BZ>знаете, что меня к хаскелу привело?
Я знаю.
BZ>высокоуровневого ассеблера? да. но для написания эффективных программ шаблоны особо и не нужны, а для написания прикоадных программ лучше испольщзовать более высокоуровневые средства. у макросов, даже в таком виде, свои недостатки — сообщения об ошибках, отсутствие run-time поддержки, время компиляции
Для написания эффективных не нужны а для избавления от лишнего цитирования и для задания компилятору лишь унивесального алгоритма выведения типов, что для определеного уровня совершенно очевидно — очень даже. Давайте не смешивать яйца с г. и они не будут не вкусными. А для написания прикладных программ годится все если уж на то пошло. Давайте тогда, если мы претенденты на абсолютную истину не ограничивать определение "прикладная" лишь стпенью собственного мышления либо восрпиятия, а говорить о степени сложности типов определяемых и оперируемых программой.
BZ>совместимость с BCPL — это ограничитель развития самого C++. ну ни к чему в один язык тащить все aborb? которые когда-либо были изобретены. а когда тащат и начинают всё вместек совмещать, "эмулировать" — тогда и выходит коктейль из switch'a с лямбдой
где вы встретили слово "все"? все не тащат а лишь добавляют логичные с точки зрения языка конструкции для определения современных концепций и тогда уж разделять языковые фитчи и навесок созданных с помощью языка. Если уж судить по мне, то замечательный коктейль и если кто то его не воспринимает, то достаточно его не трогать и он тебя не обидит.
BZ>РАЗВИТИЕ ПРОГРАММИСТА ОПРЕДЕЛЯЕТСЯ УРОВНЕМ ЗНАНИЯ СОВРЕМЕННЫХ ТЕХНОЛОГИЙ, А НЕ СПОСОБНОСТЬЮ СЭМУЛИРОВАТЬ ИХ ЧЕРЕЗ СТАРЫЕ. по очень простой причине — деньги. быстрее делаешь программу — длиннее деньги. а для интереса я и сам с удовольствием C++ со всеми его наворотами прочту (но зазубривать не стану, и не просите )
Вот за это я вам ставлю +500, за то что вы абсолютно правы и -500 за то, что вы сделали такой вывод из моего тезиса.
Перевожу для более жесткого head-safe mode.
BulatZiganshin notes:
РАЗВИТИЕ ПРОГРАММИСТА ОПРЕДЕЛЯЕТСЯ УРОВНЕМ ЗНАНИЯ СОВРЕМЕННЫХ ТЕХНОЛОГИЙ, А НЕ СПОСОБНОСТЬЮ СЭМУЛИРОВАТЬ ИХ ЧЕРЕЗ СТАРЫЕ. по очень простой причине — деньги. быстрее делаешь программу — длиннее деньги. а для интереса я и сам с удовольствием C++ со всеми его наворотами прочту (но зазубривать не стану, и не просите
Alexmoon notes:
может ведь и не хватить мозгов ее отладить даже в такой среде. все относительно.
на времени обучения сильно сэкономишь, но сильно проиграешь в развитии и гибкости.
Не связывайте эти два определения вне контекста, которого они были использованы. Это абсолютно очевидная ошибка. Сказанное вами абсолютная истина, но лишь одно уточнение, чтобы оправдать то, что было сказанно мною.
1. Чем больший набор инструментов вы не используете а можете использовать, тем больший уровень вашего развития, но. Это не значит что основопалагающие понятия в ущерб эффективности вы не должны реализовывать тем, что на чей то взгляд морально устарело. Актуально все и всегда и из пушки в воробьям — касется как и прикладухи с огромным количеством сложных понятий, реализованной на С++, так и обратного направления. Использования С# в механизмах, когда необходимо эффективное манипулирование ресурсами, а не лишь их наличие.
Я думаю что в моем иносказании я лишь забыл соскалить смайл и поэтому она несла в себе скрытую ошибку. Признаю.
BZ>ха! вот тут-то я вас и подловлю. прежде всего — вы представляете, какого уровня знаний требует рекурсвиное порграммирование на фортране IV? для рекурсивного вызова нужно завести по массиву на каждую локальную переменную, и хранить номер текущего используемого индекса в этом массиве. затем нужно обеспечить переход к нужной части порцедуры при вовзрате. но это ещё фигня — предствьте себе взаиморекурсивные вызовы нескольких порцедур!!! нынешние пограммисты и не подозревают, как много им сил сэкономили компиляторы
не нужно. я найду решение, а другум это лишь лишний раз говорит о том, что чем больший спектр задач они хотят охватить, тем более детальное изучение от них требуется.
надеюсь нам с вами выяснять нечего.
BZ>а теперь скажите, что легче — написать рекурсивную программу на фортране, или многопоточную, с автоматичсекой синхронизацией и разделением ресурсов — на хаскеле? и стоит ли хаскелловскому порграммисту указывать умение писать такие порграммы как отдельный скилл?
не стоит, но и не стоит утверждать что хаскел — это панацея и каждые скилсы имеют контекст определения инструмента, который там же указан. Никто не мешает математикам использовать свой фортран — ежели кроме математики их ничего более не интересует и это точно не обозначает, что фортран стоит запретить использовать вовсе.
Вообще концептуальная ошибка сравнивать не сравнимое. Сравнивать можно только спецификации C# от разных производителей. Все остальное, читсый фарс. И если моего уровня развития достаточно, чтобы реализовать архиватор на С++ не с меньшей эффективностью и не менее защищенный во внешней среде — это говорит совершенно не о том, что языки равнозначны, а лишь о том, что алгоритмами написания этих вещей мы владеем одинаково, но на ++ я могу писать не менее производительно чем вы на Хаскеле и НЕ БОЛЕЕ ТОГО. И слава богу, что до сих пор актуально то, что было спроектировано N корличество лет назад и все фарсы поводу выше сказанного будут справедливы лишь тогда, когда что либо превзойдет что либо с той области где он изначально асс. И без привязок к определениям, а то сейчас опять пробежимся по цепи в очередной раз.
BZ>у меня было аналогично. когда я решил присобачить к своему арзиватору read-ahead, опережающее чтение файлов в отдельном от упаковки треде, я потратил неделю. на то, чтобы во всём этом разобраться, и чтобы осознать, КАК это просто будет сделать. у меня просто мозги этого не совпринимали, как и ваши наверно сейчас разобравшись, я сделал за день, там строк 40 кода всего понадобилось. а вот ни в одлном из других арзиваторов этого до сих пор нет. почему? наверно, потому, что они все на C++ написаны
Совершенно не потому. Если бы уровень владения алгоритмами архивации был базовым, то они были бы написаны на всем.
BZ>то же самое относится и ко многим другим архиваторным фичам. у меня более интеллектуальная сортировка, разбиение на солид-блоки, выбор алгоритма сжатия и т.д. может, Рошаль и Павлов в вашей классификации и не специалисты по C++, но по крайней мере я их по многим фичам обхожу
respect.
BZ>а мне кажется — можно multi-threading, GC, лямбды и прочие вещи, которые в других языках есть изначально, и умение пользоваться эмуляцией которых в C++ рассматривается как необходимое условие для устройства на работу
а кто жестко определял список необходимых условий для приема на любую работу. каждый сам определяет набор условий и естественно набор инструментов и те кто ограничивает набор инструментов и использует эмуляцию подобного, то поему оно не должно быть требованием
Здравствуйте, VladD2, Вы писали:
VD>Это понятно. Ты ведь не видел того как может выглядеть метапрограммирование будь оно органично встроено в язык. Потому и сомневашся. А вот IT видел. Как сейчас помню восторженный его восклик в аске — "Оифигеть! Я добавил поле типа Location и забыл сделать его изменяемым, но компилятор мне сказал об этом! И это делает простой макрос!". Так что вы в разных условиях. Он видел и то, и то, а ты только шаблоны С++.
Не только, если сложилось такое впечатление и я не об этом, если это просто ваше заблуждение.
Здравствуйте, VladD2, Вы писали: E>>Сложность AI не означает интересности игры. Во многих 3D-шутерах сложную логику поведения врагов просто никто не оценит. Q3 изначально был нацелен на multiplayer, боты там, по-моему, вообще больше для тестов и начальной тренировки новичков. Ну если ты все же играешь в Q3 один, какого усложненное поведение ты хотел бы у них увидеть?
VD>Поведения неотличимого от человека. Боты в найтмаре очень похожи на человека с отличной реакций, но совсем тупого. А хочется, чтобы они делали подляны... прятались и собирали предметы когда у них мало здоровя/брони, наоборот пресинговали когда захватят ресурсв. И чтобы они мазали не рандомом, а в зваисимости от сложности обстановки. Ну, блин, противно видеть как бот попадает в тебя совершая кульбит в другом конце уровня! И наоборот, мажет в упор.
Ну не знаю из рельсы эти гады всегда попадают . А в ближнем бою человек тоже хорошо промахивается .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Женя,
E>При попытке заменить выбывшего по объективным причинам или форс-мажорным обстоятельствам человека. И здесь оказывается, что заменить Java программиста возможно. C++ программиста, в принципе, возможно. Найти адекватную замену Хаскел или Пролог программисту... Это мало реально еще и потому, что, по моим наблюдениям, те же Пролог программисты имеют очень высокий уровень, это не обычные кодеры, которым по жизни хватает один раз выученного языка и одной освоенной IDE, и работы над одинаковыми проектами. А значит, Хаскел и Пролог программисты подходят к своей работе более творчески и применяют неординарные идеи. Соответственно, удачно заменить их сможет только такой же продвинутый и неординарный человек.
И да, и нет. У меня есть два аргумента за:
1. Человек ушёл с одного проекта на Java, который он писал где-то года 2. Парень, который пришёл на замену, провёл 10 месяцев, прежде чем написал первую строчку своего кода!!! Меня просто ужас охватывал, когда он мне показывал список классов — он просто нажимает скроллинг и держал. А классы бежали и бежали. От имён уже начинало рябить в глазах, и наконец они сливались в одно непрерывное полотно, и лишь отпечатывался префикс C* или I*... По сравнению со сроком изучения системы, изучение языка это просто "о малое".
2. Потом люди, которых я знаю по жизни и в сети, с радостью бы работали на Хаскеле, дай им такую возможность. Да блин, я хоть сейчас, и даже на меньшие деньги. То есть я думаю, такие люди есть везде. Но! Найти действительно шарящего парня, которому не страшно доверить самые ответственные участки — это проблема. А как только мы его нашли, то изучить для него хоть Хаскель, хоть J, хоть N — не проблема.
Так что с позиции руководителя — 100% согласен, но с позиции практикующего программиста — только 20%
Здравствуйте, VladD2, Вы писали:
VD>ОК, поясни что за концепция языка (гы-гы, тем кто использовал этот язык 10 лет к ряду), что не позволяет просто определить атрибуты? Может их просто нет в этом языке, а средства эмуляции настолько убоги, что не позволяют это сделать качественно? Я ошибаюсь? А тогда в чем же дело?
Мне похлопать тем (гы-гы, кто использует этот язык 10 лет к ряду) от тех (гы-гы, кто использует этот язык 10 лет к ряду). Или я должен был понять, что вы именно тот человек, чей опыт и представления идеальны. Избавтесь от ошибочных представлений, а иначе я все равно не поклонюсь вам, потому что могу в силу собственного опыта понять, что это ошибочное направление.
Настолько убоги, насколько лишь вам это кажется, но это только кажется. Ваши представления и мои и чьи либо другие далеки от истины, иначе был бы уже давно единый и совершенный мир. Сказав, что можно обойтись иным преставлением, а не обязательно точным соответствием заданному определению, я имел ввиду лишь то, что не нужно натягивать различные концепции друг на друга относительно различных идиом.
То что вас ограничивает с использованием каких либо средств, не является признаком того, что это логично, а лишь признаком того, что по каким либо причинам вас это просто не устраивает. (А тут хоть что угодно определяйте. Не гибкость, не желание и т.д. и т.п.) Но это уже ваши проблемы а не комитета. Если бы это были проблемы комитета, то на языке уже никто не писал. И по моему это обсуждение уже вышло за рамки ++.
VD>В С# нет встроенного метапрограммирования. По этому и обсуждать не чего. А вот в Nemerle есть. И метапрограммирование на С++ на его фоне выглядит полнейшим извращением и убожеством.
Все верно, но это не значит что нет таких вещей, которые тоже могут являться не естественными в обратном направлении.
VD>Звучит громко? Но это правда. И чтобы ее осознать надо просто прочесть пару статей про макросы Немерле.
Прочитаю и я уж точно не ограничен приведенным вами набором определений.
Здравствуйте, jazzer, Вы писали:
J>В Математике удобнее было :)
Смотри:
J>там запись a[b[c[d[x]]]] (квадратные скобки там значат то же, что и круглые в С — вызов функции с аргументом в скобках) J>можно было выразить так: J>a[b[c[d @ x]]]
a b c d x
J>или так: J>a @ b @ c @ d @ x
a $ b $ c $ d $ x
J>или так: J>x // d // c // b // a
(//) = flip ($)
x // d // c // b // a
J>или так: J>c @ d[x] // b // a
(c $ d x) // b // a
J>ну и т.д. (пробелы необязательны)
Аналогично
J>при этом для бинарных функций был еще такой сахар: J>f[b,c] J>можно писать как J>b ~ f ~ c
Здравствуйте, Last Cjow Rhrr
LCR>2. Потом люди, которых я знаю по жизни и в сети, с радостью бы работали на Хаскеле, дай им такую возможность. Да блин, я хоть сейчас, и даже на меньшие деньги.
Имхо, зря ты так Программирование -- оно на любом языке программирование, со всеми вытекающими. Всегда почему-то возникают баги, выискивать и править которые приходится с очень большим напрягом. И всегда есть заказчики со своими тараканами. И начальство. И коллектив... Так что, когда новизна перехода на новую технологию тускнеет и исчезает, остается одна и так же рутина по выдавливанию из собственных мозгов очередной порции идей.
LCR>Так что с позиции руководителя — 100% согласен, но с позиции практикующего программиста — только 20%
У меня как раз сочетаются позиции руководителя и разработчика. Причем разработчика не только прикладного кода, но и вспомогательных библиотек. А для этого так же нужно изначально оценивать в чьи руки попадет инструмент и как сделать так, чтобы никто не считал получившийся результат неприменимым из-за излишней сложности. Причем порядочный объем написанного мной кода сейчас сопровождают другие люди, так что некоторая обратная связь также поставляет информацию к размышлению
Так что я сейчас более склонен поменять C++ не на сложный Haskell, а на что-нибудь гораздо более простое. Вроде пятого Турбо Паскаля или Oberon-а Бертран Мейер, редиска, Eiffel за деньги продает
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Вот только в чем? В красоте или в эффективности выполнения? BulatZiganshin утверждает что на хаскеле будет медленнее, хотя и более кратко и красиво.
VD>Хаскель медленный язык. Медленный в силу своей специфики. VD>Для эффективности на уровне маш.команд конечно нужно понижать уровень, а не повышать. Только уверен, что ваши проблемы эффективности лежат не на уровне сочетания процессорных инструкций, а на уровне алгоритмов. Одно только автоматическое управление памятью упрощает применение многих алгоритмов и делает возможным то на что у вас не поднималась рука ранее. А уж в купе с другими возможностями, и говорить не о чем.
Короче, прекратим этот спор, т.к. я сомневаюсь что это прокатит в указанных мной случаях. Ты же не имея опыта работы с движками тоже не можешь утверждать. Но все таки я склоняюсь к мнению Cyberaxe здесь
DC>>Но с алгоритмами они врядли способны что-то сделать, разве что упростят построение модели.
VD>Они позволяют сделать возможным мечты.
Ех Влад если бы все было так просто с моими мечтами .
VD>Ты можешь относительно просто превраить интерпретакцию в компиляцию. Макарнонный код в краткий DSL. Сгенерировать код так как тебе надо, а не так как выходит.
Я не намерен дальше продолжать этот спор. В итоге хочу сказать, что не смотря на все преимущества (более мощную поддержку метапрограммирования) С++ все равно остается неплохим инструментом и не фиг его хаять.
Здравствуйте, VladD2, Вы писали:
VD>Прблема в том, что у С++ очень куцие концепции. И рассматривая в них казалось бы простые и логичные решения оправдываются весьма уродливые решения.
Какова постановка вопроса, такова постановка ответа. Получаете ровно то, что просите.
У С++ не настолько куцые концепции, насколько куцые представления у вас о них, либо это просто упрежденное мнение и оно не может учитываться в претендентах на действительность. Если рассматриваются казалось бы простые и логичные определения, то они не оправдывают уродливые решения. Я уже сказал почему. И как бы вам не хотелось подтверждения именно ваших мыслей — это не будет, пока вы не перестанете навязываться. По частоте высказываний вы скоро потеряете связь и продолжите обсуждать сами с собой то, что давно уже будет оставлено другими.
VD>Это не так. В хорошем языке на котором можно описывать лызные гонки, например, есть понятие "снег". И без него дейсвтительно глупо говорить о лыжных гонках. Представь всебе: VD>
Бегун на плоских палках привязанных к ногам вырывается вперед...
VD>Ужас, правда? Так вот хороший язык позволяет добавлять в него новые понятия. Применительно к ЯП такими возможностями являются библиотеки фукнций и классов, а так же метапрограммирование. То что можно добавить библиотекой (при приемлемо качестве) нет смысла реализовывать метапрограммой, но далеко не все можно сделать библиотекой. Вот тут и помогает матапрограммирование. Но оказываетс, что один язык предоставляет удобные и мощьные концеции для расширения себя любимого, в адругой один хитрый патцан научился использовать побочные эффекты от рекурсивного определения шаблонов, чтобы сэмулировать примитивнеший фукнциональный язык с убогим синтаксисом и плохой связью с компилятором. В итоге на одном языке можно творить чудеса, а на другом путем неимоверных по своему садизму изнасилований мозга получать примитивнийшие решения и радоваться этому как младенец.
И таких логичных по моему мнению понятий как снег я наопределю столько что ужасов вам покажется язык, который все их вместит. Мыслите шире, коль уж вы претендуете на оправдание собственных взглядов. Остальное оффтоп. Я могу вам не меньше страшных историй рассказать.
A>> Для меня необходимым и достаточным является то, что с максимальной гибкостью я могу определить любое из высокоуровневых понятий набором базовых.
VD>Скорее с неимоверной убогостью. Но ты не поймешь этого пока будешь знать один С++, так как тут работает парадок Блаба
Это я могу воспринять только как наезд. Где было определение того, что я знаю только С++ или даже еще больше ограничиваюсь только его использованием, и даже если вы соблоговолите это признать, то это совершенно не обозначает что я полностью поддерживаю ваше мнение.
Я обязательно это почитаю, но поверьте еще до прочтения логически понятно, что даже если и мои мысли совпадут с описанным, то это не значит, что я говорил об обратном.
Здравствуйте, rameel, Вы писали:
R>Когда нечего сказать, начинают рассказывать про кривость рук
о какой кривости рук идет речь. Все вышеописанное обозначает лишь то, что если человек обслуживающий электронные системы космического корабля напартачит — это совершенно не значит что система убога, а значит лишь то, что он использует то, чьи характеристики он не поинмает до необходимой степени владения. Используй только то чем владеешь для обеспечения достаточной степени надежности.
L>>x // d // c // b // a J>Я просто смотрел на страничку по ссылке про евро, там было нечто вроде (euro=|>)
J>d x |> c |> b |> a
J>Что, очевидно, хуже того, что выше
J>Тогда не очень понятно, зачем вводить евро, если есть флип бакса
это одно и то же
a$b = a b
a//b = b a
и вышенаписанное можно точно так же записать как
x |> d |> c |> b |> a
что я собственно в своём примере и делал: bad_crcs .$ ... .$ ...
LCR>2. Потом люди, которых я знаю по жизни и в сети, с радостью бы работали на Хаскеле, дай им такую возможность. Да блин, я хоть сейчас, и даже на меньшие деньги. То есть я думаю, такие люди есть везде. Но! Найти действительно шарящего парня, которому не страшно доверить самые ответственные участки — это проблема. А как только мы его нашли, то изучить для него хоть Хаскель, хоть J, хоть N — не проблема.
LCR>Так что с позиции руководителя — 100% согласен, но с позиции практикующего программиста — только 20%
меня как-то на C# приглашали только потому, что я хаскел знаю. в history of haskell самая понравившшаяся мне фраза — представителя одной из коммереских фирм: "мы обнаружили, что поиск специалистов по хаскелу — это просто способ найти наиболее грамотных и талантливых программистов".
.
A>Это я могу воспринять только как наезд. Где было определение того, что я знаю только С++ или даже еще больше ограничиваюсь только его использованием, и даже если вы соблоговолите это признать, то это совершенно не обозначает что я полностью поддерживаю ваше мнение.
ну, не знаю, не знаю. у меня по тому, как вы гордлитесь своим умением виртуозно орудовать ломиком, сложилось впечатление, что другие инструменты вам совершенно незнакомы
Здравствуйте, jazzer, Вы писали:
J>Я просто смотрел на страничку по ссылке про евро, там было нечто вроде (euro=|>)
J>d x |> c |> b |> a
J>Что, очевидно, хуже того, что выше
Для меня неочевидно :-( Имхо, одно и то же.
J>Тогда не очень понятно, зачем вводить евро, если есть флип бакса :)
Да это просто разные названия одного и того же, и определены также. А назвать его евро, а не (//) — это стилистический приём — мол, делает то же, что и бакс только наоборот :-)
А так — это всё простые лямбды:
flip = \f -> \x -> \y -> f y x
($) = \f -> \x -> f x
(//) = flip ($)
= (\f -> \x -> \y -> f y x) (\f -> \x -> f x)
= \x -> \y -> (\f -> \x -> f x) y x
= \x -> \y -> y x
Кстати, вот такая запись (ниже) в Хаскеле всего лишь сахар для лямбд.
flip f x y = f y x
f $ x = f x
x // f = f x
Обрати внимание на определение ($) — это простое применение функции. Смысл его в том, что этот оператор имеет самый маленький возможный приоритет (в Хаскель можно определять не только операторы, но и приоритеты для них). Поэтому его используют для сокращения количества скобок, которое в чистых ФЯ стремится к бесконечности :)
Вместо a (b (c (d (e f)))) пишут a $ b $ c $ d $ e f.
E>Так что я сейчас более склонен поменять C++ не на сложный Haskell, а на что-нибудь гораздо более простое. Вроде пятого Турбо Паскаля или Oberon-а Бертран Мейер, редиска, Eiffel за деньги продает
нет-нет, это С++ — сложный язык. а хочется поменять его на что-то более простое, чтобы не заучивать наизусть библию в 1000 страниц и не мучаться от того, что вы где-то инициализацию или блокировку забыли. кстати, насчёт инициализации:
это у меня структура, содержащая все опции, так инициализируется. если где-то что-то забуду, run-time сразу выкинет мне сообщение типа "Using uninitialized cmd_arclist". это одно из преимуществ lazy evaluation
Здравствуйте, eao197, Вы писали:
E>Так что я сейчас более склонен поменять C++ не на сложный Haskell, а на что-нибудь гораздо более простое. Вроде пятого Турбо Паскаля или Oberon-а Бертран Мейер, редиска, Eiffel за деньги продает
Кстати D если запретить шаблоны тоже хороший вариант как простой язык.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>ну, не знаю, не знаю. у меня по тому, как вы гордлитесь своим умением виртуозно орудовать ломиком, сложилось впечатление, что другие инструменты вам совершенно незнакомы
я надеюсь что в данной ветке уж точно достаточно будет моего последнего аккорда. раз уж заблуждения даже по этому поводу есть, то к сожалению истина еще боле далека. Все нижесказанное, лишь уточнения.
1. Знакомы и очень даже приемлемы. Скажу вам больше и я не собираюсь себя ограничивать даже ими. Одно из качеств любого из нас — это способность быстро подстраиваться под изменение столь быстро уходящей из под ног определенности.
2. Ненавижу просто когда говорят о куцости того, о чем просто не имеют никакого морального права заявлять, как определяющее мнение.
Фразы, а мне не нравится неуместны никогда и нигде. Все что можно сделать — это послать в комитет запрос о том, что все КУЦО и СРОЧНО исправить все в течении дву недель.
3. Коль мы говорим о чем либо, то давайте не лепить в сравнение что либо другое, кроме его клонов. Это касается всех языков без исключения.
Надеюсь здесь все. Поверьте вам мне было намного приятнее выразить свои мысли, чем предыдущему собеседнику. Делайте выводы на базе оценочно сравнительной характеристики, только ради бога не высказывайте свои выводы прилюдно.
Здравствуйте, FR, Вы писали:
E>>Так что я сейчас более склонен поменять C++ не на сложный Haskell, а на что-нибудь гораздо более простое. Вроде пятого Турбо Паскаля или Oberon-а Бертран Мейер, редиска, Eiffel за деньги продает
FR> FR>Кстати D если запретить шаблоны тоже хороший вариант как простой язык.
Именно этим-то он мне и интересен.
Кстати, не обязательно запрещать шаблоны -- достаточно только не использовать их для метапрограммирования.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>это у меня структура, содержащая все опции, так инициализируется. если где-то что-то забуду, run-time сразу выкинет мне сообщение типа "Using uninitialized cmd_arclist". это одно из преимуществ lazy evaluation
Сложность функциональных языков я вижу не столько в их синтаксисе или еще каких-то внешних проявлений, сколько в необходимости выдумывания решений в функциональном стиле. Что требует серьезной перестройки сознания. В отличии от императивного подхода. Даже переход от процедурного к объектно-ориентированному стилю не требует такого сдвига в способе мышления.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
A>>Указатели есть базовое понятие с достаточной степенью свободы и насколько вы аккуратно проводите анализ составляющих, настолько мала вероятность вами ошибится.
VD>Извини, ты смарт-поинтерами пользуешся?
Очень редко, поскольку у меня нет проблем связанных с утечкой ресурсов под указателями. Но не отвергаю их с определенным количеством оговорок.
Задавай вопрос целиком. Учитывая оболочку в которой мы общаемся — это расточительство.
Здравствуйте, eao197, Вы писали:
BZ>>это у меня структура, содержащая все опции, так инициализируется. если где-то что-то забуду, run-time сразу выкинет мне сообщение типа "Using uninitialized cmd_arclist". это одно из преимуществ lazy evaluation
E>Сложность функциональных языков я вижу не столько в их синтаксисе или еще каких-то внешних проявлений, сколько в необходимости выдумывания решений в функциональном стиле. Что требует серьезной перестройки сознания. В отличии от императивного подхода. Даже переход от процедурного к объектно-ориентированному стилю не требует такого сдвига в способе мышления.
Ну, учиться всегда тяжело. Когда наступает стадия "применять", то усилий делать для декларативного мышления не надо. Ты просто мыслишь декларативно и всё :-) Полагаю, что императивному подходу тоже надо учиться. Например, сначала надо понять, что x = x + 1 — это не безграмотная формула, а изменение переменной, а для этого надо было понять, что такое переменная.
Здравствуйте, eao197, Вы писали:
E>Сложность функциональных языков я вижу не столько в их синтаксисе или еще каких-то внешних проявлений, сколько в необходимости выдумывания решений в функциональном стиле. Что требует серьезной перестройки сознания. В отличии от императивного подхода. Даже переход от процедурного к объектно-ориентированному стилю не требует такого сдвига в способе мышления.
Имхо, в том и дело, что разница декларитивного функционального подхода и императивного ООП, гораздо больше, чем последнего и имеративного же процедурного. Т.е. ООП является практически "надстройкой" над процедуным программированием, когда данные и операции "запихиваются в один флакон".
Здравствуйте, lomeo, Вы писали:
L>Ну, учиться всегда тяжело. Когда наступает стадия "применять", то усилий делать для декларативного мышления не надо. Ты просто мыслишь декларативно и всё Полагаю, что императивному подходу тоже надо учиться. Например, сначала надо понять, что x = x + 1 — это не безграмотная формула, а изменение переменной, а для этого надо было понять, что такое переменная.
Вопрос не столько в том, легко или тяжело учиться. Вопрос в конечном результате.
Для того, чтобы проломить кому-нибудь голову, можно либо несколько лет оттачивать мастерство в каком-нибудь виде единоборств, либо взять ломик потяжелее и подойти незаметно. Причем последний способ может еще и более действенные результаты давать.
Во многих случаях программирование необходимо именно для достижения не самого сложного результата. И если кому-то нравится делать это красиво и изыскано, он может постоянно заниматься самосовершенствованием. А кто-то в это время будет просто вовремя доставать ломик из-за пазухи и иметь возможность тратить свое время на что-нибудь другое.
Так вот, первых, имхо, меньшинство. Хотят они того или нет, с некоторых точек зрения проекты выгодно начинать и вести так, чтобы меньше зависеть от этого меньшинства. А раз так, то и технологии нужно подбирать такие, которые, по вполне понятным причинам, меньшинству кажутся неудачными, органиченными или вообще ущербными. Но нам, большинству, эти постоянные упреки, опять же по вполне понятным причинам, не нравяться. Поэтому мы при первой же возможности говорим: "А ну сгинь, а то ща ломом да по кумполу!"
И вообще, воинствующую посредственность еще никому не удалось победить! Поэтому мы будем жить и процветать!
Так что, помогайте талантам, а мы, бездари, сами прорвемся!
L>О чём вы спорите вообще
Это уже не столько спор, сколько объяснение собственных взглядов.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, FR, Вы писали:
FR>>Кстати D если запретить шаблоны тоже хороший вариант как простой язык.
E>Именно этим-то он мне и интересен. E>Кстати, не обязательно запрещать шаблоны -- достаточно только не использовать их для метапрограммирования.
Имхо, лучше всёж ключик иметь на всякий случай, а то и про старуху бывает порнуха...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А самолет, который я описал, движется ? Да. Летает со скоростью 100 км/час. И даже, может, и не падает. Жрет горючее как 100 Боингов, но летает PD>Ну и счастливого полета на этом качественном самолете. В соседнюю деревню, За рогами и копытами.
В реальной жизни все иначе. Например, начиная с 3-его поколения скорость истребителей в среднем снижается. Т.е. истребители 3-его поколения обычно летают несколько быстрее чем 4го, а те, в свою очередь, быстрее, чем истребители 5го, которые летают не с высокой скоростью, а с такой, какой нужно. Это, однако, не означает какого-то мифического падения качества и утраты навыков изготовления быстрых самолетов. Как раз наоборот, фактически Миг-21 или там F-4 не имеют против представителей следущего поколения вроде Су-27 или F-15 практически никаких шансов.
Самое забавное, что после второй мировой авиаконструкторы были практически одержимы скоростью и — кровь из носу — старались поднять ее как можно выше, порождая при этом кошмарных уродцев вроде "Старфайтера", которого летчики ласково называли "летающий гроб" или, например, "вдоводел" — причем вдов он делал вовсе не по другую сторону железного занавеса, и не только из жен летчиков, но и просто падая, например, на жилые дома. Обезумевшие авиаконструкторы (а они были все профессионалы, да какие — еще старой закалки, каждый — живая легенда, это потом на смену им пришли безликие инженеры, имен которых никто не знает) клепали самолеты один быстрее другого жертвуя при этом всем остальным, не в силах отказаться от своих заблуждений. Суровая правда в виде данных о боевых потерях (когда, например, F-4 несли потери в боях с Миг-17, имеющими в 2 раза меньшую максимальную скорость) заставила начать работу над ошибками, да и то далеко не сразу.
Понятное дело, все совпадения случайны.
... << RSDN@Home 1.2.0 alpha rev. 655>>
'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
Здравствуйте, Alexmoon, Вы писали:
A>о какой кривости рук идет речь. Все вышеописанное обозначает лишь то, что если человек обслуживающий электронные системы космического корабля напартачит — это совершенно не значит что система убога, а значит лишь то, что он использует то, чьи характеристики он не поинмает до необходимой степени владения. Используй только то чем владеешь для обеспечения достаточной степени надежности.
Вот я и говорю, что все сводишь к кривости рук. Думаю, людей, которые не понимают в необходимой степени характеристики системы не допустят даже пыль с приборов панели вытереть , не говоря уже о том, чтобы ее разрабатывать.
А ты не допускаешь, что ошибка в системе может быть не от не понимания, а банальной невнимательности/опечатки или говоря проще — человеческого фактара (ну, кто не грешен — киньте в меня камень ), и чтобы хоть как-то его уменьшить и пользуются всякими смарт-поинтерами, и даже стучат по пальцам тому, кто работает с голыми указателями на прямую.
Здравствуйте, rameel, Вы писали:
R>Вот я и говорю, что все сводишь к кривости рук. Думаю, людей, которые не понимают в необходимой степени характеристики системы не допустят даже пыль с приборов панели вытереть , не говоря уже о том, чтобы ее разрабатывать.
R>А ты не допускаешь, что ошибка в системе может быть не от не понимания, а банальной невнимательности/опечатки или говоря проще — человеческого фактара (ну, кто не грешен — киньте в меня камень ), и чтобы хоть как-то его уменьшить и пользуются всякими смарт-поинтерами, и даже стучат по пальцам тому, кто работает с голыми указателями на прямую.
Допускаю конечно , но и ты допусти пожалуйста то, что человеческий фактор у каждого проявляется по разному и от него не спасет ни одна фитча ни из любого языка. И бездумное использование даже смарт-поинтеров не спасет от этого, а лишь уменьшит вероятность. Я думаю нет смысла приводить, почему
Я ими не пользуюсь в 95-ти процентах и не потому что люблю когда бьют по пальцам, а лишь потому что знаю от какого фактора спасают смарт-поинтеры, а то я смотрю чем дальше, тем меня все больше пытаются в мазохисты определить.
Здравствуйте, Alexmoon, Вы писали:
A>И не потому что боюсь учиться, а потому что инструмент позволяет сделать все что необходимо
Ты не поверишь, но точно такие же фразы я слышал от людей, которые пользовались динозаврами вроде FoxPro 2.0. Это, собственно, отмазка #1 когда человек в действительности не хочет учиться.
Здравствуйте, AndrewVK, Вы писали:
A>>И не потому что боюсь учиться, а потому что инструмент позволяет сделать все что необходимо
AVK>Ты не поверишь, но точно такие же фразы я слышал от людей, которые пользовались динозаврами вроде FoxPro 2.0. Это, собственно, отмазка #1 когда человек в действительности не хочет учиться.
Совершенно с тобой согласен, с одним но, ах куда же без него. Вы как минимум обрезали контекст обсуждения, а без него эта фраза как то и мне не сильно нравится. И далее можно прочитать, что я использую не только ++, но и все что разумно вписывается в контекст решения тех или иных задач.
Я уже по моему просил не цепляться к отдельным фразам, поскольку это все достигло такого масштаба, что отвечать на отдельные посты невозможно не прочитав все дерево от начала до конца.
Я С# пользуюсь когда это нужно и только тогда и знаю что давно пора было MS создать такую платформу для себя и такое средство разработки, только это совершенно не повод гнать бочку на ++. И не вспоминайте вы сейчас уже все остальное что проходило в обсуждении, потому что определения были затронуты только потому чтобы привести более яркий пример.
Догадайтесь откуда растут ноги всего этого обсуждения? И дай вам бог для этого не читать всю эту ересь. Как кто то правильно заметил, что это уже не спор, а повод лишний раз собраться. Только время зря убиваем, честное слово.
Здравствуйте, Alexmoon, Вы писали:
AVK>>Ты не поверишь, но точно такие же фразы я слышал от людей, которые пользовались динозаврами вроде FoxPro 2.0. Это, собственно, отмазка #1 когда человек в действительности не хочет учиться.
A>Совершенно с тобой согласен, с одним но, ах куда же без него. Вы как минимум обрезали контекст обсуждения
А у меня притензии не к контексту обсуждения, а к конкретному аргументу. Опять же, я обрезал чтобы не перегружать тех, кто это читает. Поверь, кто добрался до этого сообщения прочитал весь предыдущий тред.
A>, а без него эта фраза как то и мне не сильно нравится. И далее можно прочитать, что я использую не только ++, но и все что разумно вписывается в контекст решения тех или иных задач.
Извини, но позволю себе усомнится.
A>Я уже по моему просил не цепляться к отдельным фразам, поскольку это все достигло такого масштаба, что отвечать на отдельные посты невозможно не прочитав все дерево от начала до конца.
То есть ты не помнишь свои собственные письма двухдневной давности. Ну тогда ладно.
A>Я С# пользуюсь когда это нужно и только тогда и знаю что давно пора было MS создать такую платформу для себя и такое средство разработки, только это совершенно не повод гнать бочку на ++.
Бочку в корневом сообщении темы погнали вовсе не на С++.
A>Догадайтесь откуда растут ноги всего этого обсуждения?
Зачем гадать если точно известно?
A>И дай вам бог для этого не читать всю эту ересь.
Приходится. По служебной необходимости.
A> Как кто то правильно заметил, что это уже не спор, а повод лишний раз собраться. Только время зря убиваем, честное слово.
Да, кстати, A380, про который последнее время так много говорят, летает медленнее, чем Ту-154 (на M 0.1, но все таки). Вобщем, сразу видно, где настоящий мегарулез, а где жалкая поделка халтурщиков из Airbus
... << RSDN@Home 1.2.0 alpha rev. 655>>
'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
Здравствуйте, Alexmoon, Вы писали:
VD>>Извини, ты смарт-поинтерами пользуешся? A>Очень редко, поскольку у меня нет проблем связанных с утечкой ресурсов под указателями. Но не отвергаю их с определенным количеством оговорок. A>Задавай вопрос целиком. Учитывая оболочку в которой мы общаемся — это расточительство.
Первое же залетевшее исключение...
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>А у меня притензии не к контексту обсуждения, а к конкретному аргументу. Опять же, я обрезал чтобы не перегружать тех, кто это читает. Поверь, кто добрался до этого сообщения прочитал весь предыдущий тред.
Извини, но позволю себе усомнится. Вы как минимум сделали неправильный вывод, если прочитали все до конца.
К конкретному аргументу цепляются только в том случае, когда больше не к чему цепляться и если уж наша цензура так бдит аргументы, тогда молчание золото во истину. Круче всех программируют те, кто здесь не произнес ни единого слова. Вы бы проследили лучше бы не только за мной, а за теми кто разбрасывается безпричинно словами куцо и т.д. Причем совершенно неверно и с определнными примерами панацеи от всех бед. Я уже рецепты писать начинаю.
A>>, а без него эта фраза как то и мне не сильно нравится. И далее можно прочитать, что я использую не только ++, но и все что разумно вписывается в контекст решения тех или иных задач.
AVK>Извини, но позволю себе усомнится.
В этой точке мне обсуждение начинает представляться как разговор со следователем. Вы не поверите, но я даже догадываюсь, откуда такие выводы, а вы говорите учиться не хочу. Никогда не сомневайтесь и не оглядывайтесь. Просто делайте так, чтобы необходимости в этом не было. То что я по большей части участвую только в плюсовых тусовках — это абсолютно не говорит о том, что мне больше нечего сказать, а лишь о том что мне это интереснее, а остальное лишь работа и времени нет.
А вам сделаю комплимент. У вас есть хватка вызывать людей на ненужные никому, кроме вас, объяснения.
Я вообще не вижу смысла, ни в вашем посте, на который я отвечаю ни в моем ответе, но все таки не откажу вам во внимании и удовлетворю любопытство, поскольку не знаю какие выводы вы еще можете сделать при полном отсутствии информации.
AVK>То есть ты не помнишь свои собственные письма двухдневной давности. Ну тогда ладно.
Вы покажите мне хоть один тред, который абсолютно последователен от своего начала, до конца и если следовать этим канонам, то рецепт мною выше предложен для локанизации вышеизложенного, раз вы все так хорошо помните.
AVK>Бочку в корневом сообщении темы погнали вовсе не на С++.
Если идти начиная от корня, то иожно было остановится на четвертом ответе и я стартанул начиная с тех времен, когда уже просто откровенно погнали, а не как вы говорите, слегка упомянули.
AVK>Зачем гадать если точно известно?
Мне тоже.
A>>И дай вам бог для этого не читать всю эту ересь. AVK>Приходится. По служебной необходимости.
За то что вы так бдительно относитесь к модерированию, вам безмерный respect. Но тогда найдите мне связь корнем общения и окончаниями его листьев и тогда даже я вам поверю.
A>> Как кто то правильно заметил, что это уже не спор, а повод лишний раз собраться. Только время зря убиваем, честное слово. AVK>Ну так не наде.. тьфу ты, не убивай.
Тут палка о двух концах. Я нашел оптимальный выход вести общение парралельно либо не в ущерб работе и бессмысленной болтовней на занимаюсь, а лишь стараюсь ответить на заданные вопросы и даже если вы здесь попытаетесь вывести меня на вопрос, почему относительно сказанного, количество написанных мною предложений не равно количеству поставленных знаков вопроса, то ответ будет только один. Это очевидно и не требует не нужных объяснений.
Кому требует, тому читать это бессмысленно. Главное проверить информацию на отсутствие запрещенных форумом слов.
Я смотрю что уже чудным вырисовывается окончание туссовки старых добрых коллег Не поверите, но я уже расслабился. Врядли вы дождетесь далее ответов с такой же частотой.
P.S. От проверки синтаксической корректности я до сих пор успокоится не могу
Влад действительно проверенный временем инструмент.
А ведь вы первый кто это заметил. Теперь я готов пожать руку и вашей внимательности, а мои посты проверку не пройдут точно.
Просто уже не могу не рассказать анекдота. Мой преподаватель по английскому мне рассказал. Да, я еще и английский знаю, только не спрашивайте, как меня угораздило.
Для пацанов с растопиренными пальцами даже локаничный англиский представляет собой одну сплошную проблему.
Однажды один из них попросил преподавателя доступно объяснить ему в чем разница между артиклями A и THE.
Преподаватель подумав некоторое время все таки нашел объяснение, которое подходит аппоненту.
Нууу... A — это обозначает ТИПА, а THE это уже КОНКРЕТНО.
Вам как великому ценителю аргументированного юмора, посвящается.
Только очень прошу не воспринимать посвящение шутки, как аргумент привязывающий какие либо определения.
Думаю хоть сейчас я сделал все необходимые проверки для правильной трактовки собственных мыслей, в контексте форума.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, dr.Chaos, Вы писали:
DC>>Влад удобнее хотя бы потому, как это проверенный временем инструмент.
AVK>Да, Влад безусловно проверенный временем инструмент А для чего он удобен, если не секрет?
Как для чего? Для разведения флейма .
ЗЫ Если уж придираться к орфографии и грамматике, давай придираться ко всем .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
E>>Даже не знаю, что сказать. У нас эта цифра составит, наверное, процентов 10.
VD>Извини, но мой опыт не позволяет мне с тобой согласиться.
С чем конкретно ты не согласен? С тем, что у нас на проекте так обстоят дела? Извини, но в этом вопросе я считаю себя более осведомоленным. Ты, конечно, можешь мне не верить, переубеждать не буду.
VD>Да и доверия этому товарищу все же больше. Как ни как в Анрыл я играл чуть ли не 10 лет назад.
Ты в курсе, что анрил, о котором рассказывается в презентации — вовсе не тот, в который ты играл?
Это новый движок, на котором пока сделана только одна игра — упоминаемая Gears of War.
E>> Утечки в начале были, но после того, как всем программистам объяснили, что такое смартпоинтер, об утечках тоже забыли и не вспоминают уже года два.
VD>Вот она ключевая фраза — "уже года два"! То есть вы убили время еще тогда, и теперь еще 2 (!) года возитесь с проектом! А могли бы ВООБЩЕ не возиться с этими проблемами!
Тебя шокировала цифра "2 года"? А ты знаешь, что движок, о котором рассказывается в презентации, делали 5 лет? А потом еще два года первую игру на нем?
<живописуемые ужасы C++ поскипаны>
У меня есть два предложения, касательно дальнейшего разговора, исключительно для экономии времени и чтобы не повторяться, предлагаю:
— не нужно рассказывать мне, чем плох C++, я в курсе;
— не нужно рассказывать мне, что происходит у меня на проекте, я это знаю лучше, чем ты.
E>>У нас главная проблема — это макароны и все, что с ними связано.
VD>А ты представь себе на минуточку, что автор презентации организовал работу так, что код у них стал хорошим. Вот он и высказывает свои мысли о том как еще улучшить процесс разработки.
E>> Неправильная декомпозиция или ее отсутствие. Решения типа "сейчас пускай заработает, а потом я сделаю правильно" (а потом он уволился). Куски кода, к которые последовательно приложило лапу 2-3-4 человека, и никто уже не помнит, что он там и зачем делал.
VD>Это тяжело объяснить, но поверь, все перечисленное тобой умножается на проблемы языка. Вот вы и получаете 2 года разработки после того как какзалось бы всем все объяснили.
Мы объяснили им это через пару месяцев после начала кодинга, после того, как в первый раз запустили Bounds Checker и увидели лики. Поверь, 2 года — не очень большой срок для разработки игры, те же Half Life 2 и Doom 3 делали дольше в разы.
VD>К тому же ты вдумайся в свои слова "объяснили всем что надо". Это значит, что вы ограничили язык до некого сабсета. Причем контролирвать это будут люди. Ты конечно потом сможешь позлорадствовать, что мол эти козлы наколбаслии, да я бы такоего никогда не допуситл... но время уйдет. По этому все что может контролировать машина должна контролировать машина. А твоя задача сфомрмировать процесс производства ПО так чтобы этот контроль был. Сюда входит выбор инструмента, и выработка тех.процессов.
С этим согласен. Лучше бы язык был получше, побезопасней, повыразительней. Я же с этим не спорю. Я только говорю, что работать на С++ можно и не так все страшно. Когда проект начинался, выбирать было особо не из чего, C# был 1.0, на Джаве страшно тормозил соседний проект, о Немерле никто и не слыхал. На чем я буду писать следующий зависит не столько от меня, сколько от того, кто у меня будет работодатель
Игроделанье оказалось ужасно неблагодарным занятием
E>>Идею, которые ты двигаешь в массы, я понял уже давно Но, как видно из начала сообщения время уходит не столько на борьбу с С++, сколько на борьбу с ошибками проектирования и организации разработки.
E>>На самом деле, идея попытаться переписать менее критичную по производительности часть проекта на C# когда-то была, но было не вполне понятно, как совместить управляемый код с неуправляемым, ну и времени, как обычно, не хватило.
VD>На самом деле это не сложно. Но C# вам даст меньший выигрышь нежели Nemerle. Так что если убить некоторое время (возможно по вечерам) на его изучение, то глядишь следующий проект не будет делаться более двух лет.
Самообразование — это правильно. Вот только дочитаю вон тот томик по теории алгоритмов, и непременно возьмусь за Немерле. Или за Хаскель. Или еще за что-нибудь
E>Самообразование — это правильно. Вот только дочитаю вон тот томик по теории алгоритмов, и непременно возьмусь за Немерле. Или за Хаскель. Или еще за что-нибудь
Здравствуйте, WolfHound, Вы писали:
VD>>>Извини, ты смарт-поинтерами пользуешся? A>>Очень редко, поскольку у меня нет проблем связанных с утечкой ресурсов под указателями. Но не отвергаю их с определенным количеством оговорок. A>>Задавай вопрос целиком. Учитывая оболочку в которой мы общаемся — это расточительство. WH>Первое же залетевшее исключение...
Краткость — сестра таланта. Хоть уже и близко не лежит в контексте обсуждения, но причины и первого и последнего мне понятны.
Андрей, даже искренне уважая стремление и тебя и всех остальных достичь истины, мне кажется это уже не имеет к данной теме ни малейшего отношения.
Здравствуйте, BulatZiganshin, Вы писали:
E>>Самообразование — это правильно. Вот только дочитаю вон тот томик по теории алгоритмов, и непременно возьмусь за Немерле. Или за Хаскель. Или еще за что-нибудь
BZ>что за томик?
Ничего особенного, один из многочисленных седжвиков. Почувствовал себя неучем в алгоритмах, устроил себе ликбез.
BZ>кстати, весьма фундаметальная книжка — http://greenteapress.com/semaphores/downey05semaphores.pdf . как вы понимаете, про те самые старые способы распарралеливания программ
За книжечку спасибо.
Здравствуйте, Alexmoon, Вы писали:
VD>>>>Извини, ты смарт-поинтерами пользуешся? A>>>Очень редко, поскольку у меня нет проблем связанных с утечкой ресурсов под указателями. Но не отвергаю их с определенным количеством оговорок. A>>>Задавай вопрос целиком. Учитывая оболочку в которой мы общаемся — это расточительство. WH>>Первое же залетевшее исключение... A>Краткость — сестра таланта. Хоть уже и близко не лежит в контексте обсуждения, но причины и первого и последнего мне понятны. A>Андрей, даже искренне уважая стремление и тебя и всех остальных достичь истины, мне кажется это уже не имеет к данной теме ни малейшего отношения.
Ты на конкретный вопрос ответь: Как ты с исключениями то живешь? Или ты их не используешь?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, jazzer, Вы писали:
J>>Я просто смотрел на страничку по ссылке про евро, там было нечто вроде (euro=|>)
J>>d x |> c |> b |> a
J>>Что, очевидно, хуже того, что выше
L>Для меня неочевидно Имхо, одно и то же.
ну мне показалось, что нельзя написать x |> d |> с и т.д.
Если можно — все ОК, просто это непонятно из статьи.
Если нельзя — это нерегулярность синтаксиса, которая бьет по глазам.
Все остальное — понятно Надо будет внимательнее посмотреть на Хаскель. Интересно, навыки программирования Математики пригодятся или нет?
Хотя, в любом случае, не очень понятно, как его сопрягать с существующими системами и инфраструктурами (которые на C/C++).
В Математике все просто было, хоть и через одно место — можно было очередную функцию определить как принимающую только аргументы определенного типа, и сказать, что она определена в DLL, после чего, заюзав MathLink (если я правильно помню название их API), написать эту самую DLL, которая быстро посчитает то, что нужно, без всяких маршаллингов и прочего (в моем случае это был поиск нескольких собственных значений и соответствующих векторов одной охренительных размеров матрицы — это я диссер считал)...
Соответственно если ейный ФП-движок принимал решение, что надо позвать именно эту функцию — начинала работать функция из DLL.
Как с этим в Хаскеле? Если в двух словах? Офтопик, конечно... Хотя в "Философии", наверное, можно...
Здравствуйте, WolfHound, Вы писали:
WH>Ты на конкретный вопрос ответь: Как ты с исключениями то живешь? Или ты их не используешь?
На конкретный вопрос, конкретный ответ.
Использую конечно. Куда же без них родимых. Скажу больше, я их даже бросаю их иногда для выявления собственных ошибок, вот только знаю куда и что необходимо сделать в точке перехвата. Мое извращение дошло до того, что я даже поинтересовался какие обертки строит компилятор для их реализации, чтобы спать спокойнее и не я вам открою тайну там сюрпризы есть. На ответ, нравится или нет, отвечу. Совершенно спокойно к этому отношусь. просто считаю за должное знать.
Андрей. Честно, положа руку на сердце. Это уже не к месту. Я отвечу на все твои вопросы, но уже при личной встрече. Если столбик термометра перевалит за 800 — это уже лишнее для чего угодно.
Здравствуйте, Alexmoon, Вы писали:
A>Использую конечно. Куда же без них родимых. Скажу больше, я их даже бросаю их иногда для выявления собственных ошибок, вот только знаю куда и что необходимо сделать в точке перехвата.
А между точкой выброса и точкой обработки как ресурсы освобождаешь?
Лично я не представляю как в присутствии исключений без оберток можно надежно освобождать ресурсы.
Вернее знаю один способ но уж лучше обертки.
A>Андрей. Честно, положа руку на сердце. Это уже не к месту. Я отвечу на все твои вопросы, но уже при личной встрече.
Это весьма маловероятное событие.
A>Если столбик термометра перевалит за 800 — это уже лишнее для чего угодно.
Ты про колличество сообщений в теме? Так это же флейм.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
J>>>d x |> c |> b |> a
J>ну мне показалось, что нельзя написать x |> d |> с и т.д.
посмотри на его объявление:
a |> b = b a
его чисто синтаксически можно подставить:
x |> d |> с
превращается в
(d x) |> c
а это в свою очередь в
c (d x)
J>Все остальное — понятно Надо будет внимательнее посмотреть на Хаскель. Интересно, навыки программирования Математики пригодятся или нет?
J>Хотя, в любом случае, не очень понятно, как его сопрягать с существующими системами и инфраструктурами (которые на C/C++). J>В Математике все просто было, хоть и через одно место — можно было очередную функцию определить как принимающую только аргументы определенного типа, и сказать, что она определена в DLL, после чего, заюзав MathLink (если я правильно помню название их API), написать эту самую DLL, которая быстро посчитает то, что нужно, без всяких маршаллингов и прочего (в моем случае это был поиск нескольких собственных значений и соответствующих векторов одной охренительных размеров матрицы — это я диссер считал)... J>Соответственно если ейный ФП-движок принимал решение, что надо позвать именно эту функцию — начинала работать функция из DLL.
J>Как с этим в Хаскеле? Если в двух словах? Офтопик, конечно... Хотя в "Философии", наверное, можно...
буквально сегодня отвечал
> I would like to use FFI for the first time. Can someone > give me a really, really simple complete example?
Здравствуйте, VladD2, Вы писали:
VD>>>К сожалению они добились полностью протевоположенного результата. DC>>Какого? Переносимости на уровне исходников нет? . VD>Ага. Странно что ты считашь себя С++-программистом и не знал этого. Полной переносимости нет, так как компиляторы не реализуют стандарт, и так как стандарт изобилует кучей мест где возможно UB. Про то что такое UB объяснять надо?
Это точно.
Вот сейчас думаю как заставить FreeImage не сваливаться в terminate под gcc 3.3 при обработки битых картинок.
Хотя на VC++8 все работает как часы.
А все по тому что VC++8 дает по сишным функциям летать исключениям, а gcc нехочет ни в какую.
И все из-за разработчиков libjpeg
/*
* Error exit handler: must not return to caller.
*
* Applications may override this if they want to get control back after
* an error. Typically one would longjmp somewhere instead of exiting.
* The setjmp buffer can be made a private field within an expanded error
* handler object. Note that the info needed to generate an error message
* is stored in the error object, so you can generate the message now or
* later, at your convenience.
* You should make sure that the JPEG object is cleaned up (with jpeg_abort
* or jpeg_destroy) at some point.
*/
METHODDEF(void)
error_exit (j_common_ptr cinfo)
{
/* Always display the message */
(*cinfo->err->output_message) (cinfo);
/* Let the memory manager delete any temp files before we die */
jpeg_destroy(cinfo);
exit(EXIT_FAILURE);
}
а разработчик FreeImage'а на радостях начал из этой функции исключения кидать.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>Ну-ну, вон три человека сумели компилятор С++ с экспортом шаблонов написать, да еще и на С. Наверное, справились бы и с немерле.
Здравствуйте, jazzer, Вы писали:
J>Все остальное — понятно Надо будет внимательнее посмотреть на Хаскель. Интересно, навыки программирования Математики пригодятся или нет?
Пригодятся. В Математике тоже используются функции высшего порядка и, кажется, частичное применение. На самом деле, до монад Хаскель пролистывают очень быстро и думают — что за игрушечный язык?
J>Хотя, в любом случае, не очень понятно, как его сопрягать с существующими системами и инфраструктурами (которые на C/C++).
Про FFI уже Булат сказал. Я, к сожалению, не успел
Здравствуйте, Sinclair, Вы писали:
A>>Нету. Представьте себе. Снег — это то что мы таковым назвали исходя из определенных характеристик свойственных такому состоянию среды. S>Ну, начинается.
Продолжается. Кидаясь не привязанными к контексту обсуждения понятиями, вы просто обязаны ожидать соотвтетствующих ответов.
S>>>Вот это утверждение хотелось бы как-то обосновать. Кто гибче — С или С++? А ведь С++ лаконичнее! A>>Обосновывать это можно до бесконечности. Для этого как минимум должны быть взаимосогласованные определения. Их не было и не будет. Всех нас всегда будет что то не устраивать. Здесь нечего ответить, поскольку поставьте вопрос на абстракцию выше и вы поймете почему все от всего зависит и выиграть во всем абсолютно не возможно. Каждый выбирает обязательные критерии сам. Главное чтобы выбор был. Вы еще помните концепцию начала и в чем конечный вывод должен состоять? S>Перечитал три раза, ничего не понял. Попробуй сосредоточиться и ответить на два вопроса: какой из языков гибче — С или С++? Какой из языков лаконичнее?
Смотря что вы хотели понять и сочетается ли это с тем, что я хотел объяснить.
Для меня это вообще не вопрос, а для вас лишь скажу, что проанализировав все выше или ранее сказанное, вам достаточно информации для того чтобы сделать свой собственный вывод.
S>Поясняю: все эти "условно-одинаковые" подходы одинаковы только математически, при пренебрежении стоимостью разработки. На практике выигрывает та техника, которая позволяет сделать разработку дешевле. В основном за счет сокращения объема кода (в лексемах, естественно, а не в байтах) и автоматизации QA. S>Нельзя отвлекаться от цели при анализе языков программирования. Все эти class, private, protected, namespace — они не сами по себе. Они только для того, чтобы сделать разработку дешевле.
Поясняю: все эти "условно-одинаковые" подходы одинаковы только математически, при пренебрежении стоимостью разработки. При пренебрежении стоимостью разработки, качество не константно, поэтому только данный аргумент никакого отношения к абсолютному определению коэффциента выиграша не имеет. За счет сокращения кода в лексемах, выиграет только адресное пространство жесткого диска. Автоматизация QA вообще к используемому средству не привязана никак. Если этот вывод не очевиден кому либо, то и я здесь помочь не смогу. Такова селяви.
Все эти class, private, protected, namespace — они не сами по себе. Они только для того, чтобы сделать разработку дешевле.
Вау. А я думал что для определения пользовательских типов, уровней доступа и локализации пространств имен. За уточнение спасибо. И они не эти. Я их уважаю.
S>Это обязательно? Сильна страсть к математике? Или неочевидно, что из этого компактнее: S>
obj->>class->method(obj, 1);
obj->>method(1);
S>
При наличии условия или мне достаточно ответить на один из вопросов условия? Отвечаю. Сильна страсть к математике. Если что то не так, то я тогда вас не понимаю аналогично тому, как вы меня. Неочевидно?
S>? Или непонятно, вызов какой из функций будет лучше проверен компилятором: S>
S>add(a, b)
S>{
S> int a;
S> int b;
S> return a+b;
S>}
S>
S>или S>
S>int add(a, b) { return a + b; }
S>
Вообще исходя из условия выше, я мог не отвечать на эту часть общего вопроса, но ладно. Мне понятно. Только я три раза прочитал и так и не понял, к какому компилятору то вопрос. Я вроде бы не говорил, что я компилятор.
A>>Запросто. Помимо человеко-лет есть набор составляющих уравнения, которые позволяют откатить человеки годы до вменяемой составляющей с учетом определенного уровня владения. S>А можно то же самое по-русски? Ниче ведь не понятно: что такое "откатить"? Эаплатить откат? И что такое "вменяемая составляющая"? А что значит "учет определенного уровня владения"? Это что-то из бухгалтерии?
А я на каком языке написал. Странно. С кодировкой проблем не замечено. Не нравится откатить, закатывайте. О деньгах речи не было. Это не из бухгалтерии, а из юриспруденции. Уровень владения теми или иными вещами напрямую зависит от уровня занимаемой должности.
Не смешно? А мне смешно. Что будем делать?
Антон. Я сказал, что хотел уже давно. Ни в ваших словах, ни в моих откровенной лжи или некомпетентности замечено не было. Еще вопросы? Все всем давно ясно. От флейма я устал.
Чтобы вы не воспринимали все на личный счет еще раз поднимем бакалы
Не нужно так ставить вопросы, если вы не готовы принять такие же ответы. Ничего личного, только конструктивное общение.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>create_archive_structure | read_input_files | compress | write_to_archive
BZ>в свою очередь, compress разделяется ещё на несколько тредов, последовательно сжимающих данные. разве это не красиво? и позволило мне это реализовать именно наличие higher-order funcs. я думаю о своей программе не в плане отдельных значений которые нужно обработать, а в плане алгоритмов, из которых конструируются более сложные алгоритмы, при этом средства их конструирования также являются алгоритмами. вот это и есть метаподход к программированию на уровне хаскела
BZ>при этом одновременно я пишу и на C, так что могу сравнивать
Ты один работаешь или в команде?
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Извини. Только сейчас и случайно заметил. Уже практически не слежу за веткой.
WH>А между точкой выброса и точкой обработки как ресурсы освобождаешь?
Об автоматических объектах вопрос наверное не стоит. Раскручивание стека — вещь понятная. Но раз зашла речь о сырых указателях то уж куда без объяснений.
Если я завожу локальный указатель и при этом еще и выделяю под него память, то на это у меня может быть несколько причин. Либо он мне нужен для перемещения внутри объекта с более глобальной областью видимости, либо он мне нужен для трансляции в более глобальный контейнер указателей, который сам имеет механизмы уборки за собой, ежели организован по такому принципу. Возможно я перечислил бегло не все варианты необходимости, но поверьте на все варианты, есть безопасные алгоритмы слежения за ресурсами.
1. Если он мне нужен для перемещения по памяти занимаемой объектом с более глобальной областью видимости, то о каком освобождении идет речь. Ежели я выделяю под него память и при этом я не имею 100% уверенности что после выделения, до достижения точки присвоения не возникнет исключения, я ставлю перехватчик обязательно в области видимости указателя и как минимум ставлю фильтр на выброс всех описанных спецификацией исключений, алгоритмами выделения. И в зависимости от того где было перехвачено исключение я делаю соответствующие выводы. Все остальное — ошибка программиста, may be. Мог конечно что то и упустить при беглом описании. Не статья, чтобы над ней работать, но суть реализации такова. Я думаю всегда, даже когда знаю что делаю. Это помогает мне не напрягаться отсутствием элементарного внимания в некоторых случаях.
WH>Лично я не представляю как в присутствии исключений без оберток можно надежно освобождать ресурсы. WH>Вернее знаю один способ но уж лучше обертки.
Возможно и я знаю тоже что и ты, но как минимум у нас есть все для нахождения собственного решения.
A>>Андрей. Честно, положа руку на сердце. Это уже не к месту. Я отвечу на все твои вопросы, но уже при личной встрече. WH>Это весьма маловероятное событие.
Я приеду, если пригласишь
A>>Если столбик термометра перевалит за 800 — это уже лишнее для чего угодно. WH>Ты про колличество сообщений в теме? Так это же флейм.
Здесь ты меня понял абсолютно точно.
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>А это один из критериев качества. Быстрее, меньше памяти требуется и т.д.
AF>Качество — это когда программа делает свою работу правильно, не падает и не рушится.
В понятие "правильности" может входить и определенное время реакции. Особенно актуально это для систем реального времени (к которым, в общем-то и игры можно отнести) и массового обслуживания (СУБД, веб-серверы и т.п.)
AF>А скорость — это отдельный параметр, и к качеству никакого отношения не имеет.
Имеет. Сможешь ли ты играть в игру со скоростью вывода 1 fps? Хотя она не падает.
ИМХО, качественная программа — программа, выпоняющая возложенную на нее задачу.
Здравствуйте, CreatorCray, Вы писали:
VD>>Из ГУИ януса я делал только дерево. CC>Это то, которое при сворачивании иногда неправильно перерисовывается оставляя хвост?
А ты еще древнее Янус надыбай и не то будет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Кстати, поиском не нашел. Говорят, манифестом можно сделать у него потребный вид по win2k... Сцылочкой не поделитесь?
Здравствуйте, Alexmoon, Вы писали:
VD>>Извини, ты смарт-поинтерами пользуешся?
A>Очень редко, поскольку у меня нет проблем связанных с утечкой ресурсов под указателями. Но не отвергаю их с определенным количеством оговорок. A>Задавай вопрос целиком. Учитывая оболочку в которой мы общаемся — это расточительство.
Не могу. Он (точнее они) зависит от твоих ответов.
Раз пользушся, то не подскажешь зачем? Темболее что "проблем связанных с утечкой ресурсов под указателями".
И еще один вопрос. Я правильно понял, что ардесной ирифметикой ты пользуешся в своих программах довольно часто?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>так это готовые, особенно твоё. дело-то именно в том, что хаскел предоставляет мощные средства КОМПОЗИЦИИ простых операций, в то время как для популярных языков существуют готовые бибилиотеки, где реализована куча алгоритмов. но выйди за пределы этих библиотек. наличие rfind ничем не поможет тебе в работе в lazy списками или деревьями. речь идёт именно о возможностях конструирования алгоритмов, предоставляемых языком
Остается заметить, что не только Хаскель. И то что ленивость хаскеля на строках сослужит ему плохую службу в отношении производительности. Особенно если учесть, что строки в Хаскеле являются списками. Оверхэд там огого получается. Для работы со строками я бы все же предпочел бокатый набор готовых функций и их композицию. А представлять строку лучше массивами, а не списками. Уж больно часто и интенсивно они исползуются.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Да уж... Rocket science... То, что ты изобразил на C#, на C++ выглядит, мягко говоря, не сложнее: str.rfind(' ', 80)
Согласен такой примитив даже в С++ в библиотеки запихнут. Что скажешь по поводу других примеров?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alexmoon, Вы писали:
A>У С++ не настолько куцые концепции, насколько куцые представления у вас о них, либо это просто упрежденное мнение и оно не может учитываться в претендентах на действительность.
Оба допущения не врены. Идем дальше.
A>Если рассматриваются казалось бы простые и логичные определения, то они не оправдывают уродливые решения. Я уже сказал почему. И как бы вам не хотелось подтверждения именно ваших мыслей — это не будет, пока вы не перестанете навязываться. По частоте высказываний вы скоро потеряете связь и продолжите обсуждать сами с собой то, что давно уже будет оставлено другими.
Осмыслености в этом не обнаружил, так что отчечать не начто.
A>И таких логичных по моему мнению понятий как снег я наопределю столько что ужасов вам покажется язык, который все их вместит.
Русский меня вполне устраивает. Ужасом его не считаю. Многие знатоки аглийского видимо тоже самое сказали бы и про него.
A>Мыслите шире, коль уж вы претендуете на оправдание собственных взглядов. Остальное оффтоп. Я могу вам не меньше страшных историй рассказать.
Опять пустословие.
A>Это я могу воспринять только как наезд. Где было определение того, что я знаю только С++ или даже еще больше ограничиваюсь только его использованием, и даже если вы соблоговолите это признать, то это совершенно не обозначает что я полностью поддерживаю ваше мнение.
Это видно не вооруженным взглядом. Может ты и знаешь еще с сотню менее мощьных языков (однотипных), но сути дела это не меняет. Твое явное непонимание того что тебе высказывают говорит само за себя. Обижаться тут бессиленно. Надо или преркащать идсскуюссию и оставаться в блаженном неведении или все же попытаться изучить альтернативы и вести разговор используя общие понятия.
A>Я обязательно это почитаю, но поверьте еще до прочтения логически понятно, что даже если и мои мысли совпадут с описанным, то это не значит, что я говорил об обратном.
Звучит как "Если у вас нет паранои, то это не значит, что за вами не следят.".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alexmoon, Вы писали:
VD>>Это понятно. Ты ведь не видел того как может выглядеть метапрограммирование будь оно органично встроено в язык. Потому и сомневашся. А вот IT видел. Как сейчас помню восторженный его восклик в аске — "Оифигеть! Я добавил поле типа Location и забыл сделать его изменяемым, но компилятор мне сказал об этом! И это делает простой макрос!". Так что вы в разных условиях. Он видел и то, и то, а ты только шаблоны С++.
A>) Не только, если сложилось такое впечатление и я не об этом, если это просто ваше заблуждение.
ОК, тогда тебе не составит труда описать известные тебе языки с встроенными возможностями метапрограммирвоания объяснить почему ты считашь, что С++-ное метапрограммирвоание на шаблонах лучше, или хотя бы не хуже. Не составит?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>знаете, у меня из богатого опыта отношение к метапрограммированию умеренное — с однйо стороны, конечно, хорошо, что язык можно расширять, не дожидаясь автором компиляторов и комитетчиков. с другой стороны, поддержка возможностей языка — это не только компиляция. а сообщения об ошибках? а отладка? а понимание того, как эта хреновина вообще работает? а взаимодейтсиве с системой типов? те же шаблоны в С++ появились как раз как замена макросов препроцессора — очень уж неудобно с ними было
Добро пожаловать в мир где эти вопросы практически решены — в мир Nemerle!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alexmoon, Вы писали:
A>Здравствуйте, VladD2, Вы писали:
VD>>ОК, поясни что за концепция языка (гы-гы, тем кто использовал этот язык 10 лет к ряду), что не позволяет просто определить атрибуты? Может их просто нет в этом языке, а средства эмуляции настолько убоги, что не позволяют это сделать качественно? Я ошибаюсь? А тогда в чем же дело?
A>Мне похлопать тем (гы-гы, кто использует этот язык 10 лет к ряду) от тех (гы-гы, кто использует этот язык 10 лет к ряду). Или я должен был понять, что вы именно тот человек, чей опыт и представления идеальны.
На мой взгля наличие опыта С++ не побязательно для формированиях хороших представлений, но это уже так к слову.
Хлопать тоже не надо. Просто твои предположения не верны. Я писал на С++ 10 лет. Правда тогда еще шаблоны были по слабее (в начале их вообще не было), и СТЛ мы не использовали так как он появился после того как мы сделали свои библиотеки, но это мелочи. Вольфхаунд и сейчас зарабатывает хлеб программированием на С++ просто потму что за него сейчас платят хорошо. И он уж точно на современных выкрутасах С++ не одну собаку съел.
В общем, ты лучше спроси. А то видишь, что люди что-то критикуют и сразу строишь предположения о низкой компетенции в этой области.
A> Избавтесь от ошибочных представлений, а иначе я все равно не поклонюсь вам, потому что могу в силу собственного опыта понять, что это ошибочное направление.
Твой опыт однобог. Это я вижу очень четко. Ты узкий специалист, о которых говорил Козма Прутков. И вместо того чтобы спросить о чем мы ведем речь и проинализировать эти слова, ты сразу делаешь выводы на основании своего опыта. Это не констрктивно. Это все равно что закрыть глаза перед акулой и представить что ее нет. Может так и спокойней, но спокойствие это илюзорно.
A>Настолько убоги, насколько лишь вам это кажется, но это только кажется. Ваши представления и мои и чьи либо другие далеки от истины, иначе был бы уже давно единый и совершенный мир.
К сожалению совершенству мира мешают такие человеческие грехи как косность, посредственность, лень, трусость, неумение менять привычки. Одни боятся изучать новое. Другим лень. Третьи просто не способны на это интеллектуально. Четвертым все до лампочки. Пятые так привыкли к убогости, что не могут даже представить как жить по другому. И т.д, и т.п.
Вот, ты наприммер, за все время полемики даже не разу не удосужился уточнить "А что же мы предлагмем взамен?". Видимо не интересно. Ведь ты уже в этой жизни для себя все решил. Есть правильный путь, и он тебе звестен. Я угодал?
A> Сказав, что можно обойтись иным преставлением, а не обязательно точным соответствием заданному определению, я имел ввиду лишь то, что не нужно натягивать различные концепции друг на друга относительно различных идиом.
Представь себе идеомы бывают более и менее удачными. А бывает так, что что-то новое полностью поддерживает идиомы старых решений и предлагают кое-что нове. Или поддерживает идиому более чистым образом. Ну скажем, поддерживает метапрограммирование напрямую, без александревсовских ухищрений.
A>То что вас ограничивает с использованием каких либо средств, не является признаком того, что это логично, а лишь признаком того, что по каким либо причинам вас это просто не устраивает.
А что же нелогичного в том, что нас что-то не устраивает? Может быть мы знаем как можно делать тоже самое, но лучше?
A> (А тут хоть что угодно определяйте. Не гибкость, не желание и т.д. и т.п.) Но это уже ваши проблемы а не комитета. Если бы это были проблемы комитета, то на языке уже никто не писал. И по моему это обсуждение уже вышло за рамки ++.
Не. Это конечно не проблемы комитета. Ему просто по барабану. Это вообщене человек. У него нет единого мнения. Да и язык от тупого животного по имени комитет не помрет сразу. Он будет медленно деградировать или просто остановится в развитии.
VD>>В С# нет встроенного метапрограммирования. По этому и обсуждать не чего. А вот в Nemerle есть. И метапрограммирование на С++ на его фоне выглядит полнейшим извращением и убожеством. A>Все верно, но это не значит что нет таких вещей, которые тоже могут являться не естественными в обратном направлении.
Да, уж. Не поспоришь. Один факт не отрицает гипотетической возможнсоти наличия дугого.
Но первый факт остается фактом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>я например вполне поддерживаю Влада в том, что Немерле быстрее хаскела, и в свою очередь языки с нативной компиляцией вероятно быстрее байткодовых
Вобще-то Хаскель как раз компилируется в нэйтив-код. Я ошибаюсь?
Байтод же дотнета никогда не исполняется в режиме интерпретации. Он всегда компилируется.
Так что если разница есть, то она определяется не байткодом, а другими вещами. Опимизацией компияторов (можно найти С++-компилятор который будте работать медленее хасклея во многих случаях, например) и герераторов нэйтив-кода. Качеством библиотек. Способом абстрагирвоания. Несомненно С/С++ позволяют выжать из железа больше при должном рвении. Но так же несомненно, что это больше выжимается очень редко. И не редки случаи кода на С++ пишут крайне медлительный код (иногда даже не осознавая этого). Утверждение "С++ самый быстрый" самое большое заблуждение. Код пишет программист. А С++ инструмент позволяющий оптимизировать в малом. Но на больших объемах он может сослужить плохую службу.
BZ>вопрос "если наш язык так крут, почему же его никто не использует?" в сообществах small языков возникают куда чаще, чем здесь есть даже статья об этом профессора Вадлера, одного из авторов Haskell и generic Java. если кратко, то дело (помимо объективных свойств самого языка) в *инфораструктуре*: библиотеках, средствах разработки, книгах, обучении и в конечном счёте подготовленных специалистах
Все это действительно влияет на популярность языка. Но разные Вадлеры, на мой взгляд, очень глубого заблуждаютя если считают эти факторы определяющими. Намного важнее интуитивность, привычность и применимость на практике. Так вот языки типа Хаскеля неинтуитивны, непривычны и очень плохохо применимы на практике. А перечисленное тобой — это всего лишь объяснение того почему они не применимы на парктике. Но неинтуитивность и непонятность куда важнее. Но тут уже Валдеры становятся Блаб-ами. Они смотрят на других со своей точки зрения и не хотят принять в рассчет точку зрения других.
BZ>спецы по Прологу или Немерлу — хорошие программисты не потому, что язык хорош. я вот скажем пишу на хаскеле, си и delphi, так что — мои способности каждый день меняются? дело в том, что для изучения скажем ООП+ООД уже есть хорошо накатанная колея, этому учат с института и человек думает о программе в этих терминах на автомате, воспринимает их как нечто соверщшенно ращзумеющееся — точно так же, как умение говорить. как мне Влад говорил, "на самом деле мир — императивен"
С обучением вообще "труба". Все что я пробовал читать по ФП никода не годится. Это писанина сумашедших ученых погрязщих в теоритическом булшите. Их труды скорее способны отбить желание изучать предмет.
Тут нужна литература столь же доступная как труд Кхернигана. Уверен, что успех С во многом определяется его книгой.
BZ>людей, способных изучить и эффективно применять какой-нибудь язык, для которого нет хорошо накатанных паттернов, тем более для которого нет отладчиков, библиотек и т.д. -
Вопрос отладчиков, библиотек и IDE очень важен. И его надо решать. Это один из фаторо останавливающих программистов в изучении и применении новых языков. После Дельфи, ИДЕИ и VS 2005 мало кто захочет писать код в нотпэдах или даже в Вимах и Емаксах.
Вот в отношении Немерла мы как раз работаем над этим. И уверен, что если будем меньше ошиватьс на этом форуме, то добьемся успехов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>Имхо, в том и дело, что разница декларитивного функционального подхода и императивного ООП, гораздо больше, чем последнего и имеративного же процедурного. Т.е. ООП является практически "надстройкой" над процедуным программированием, когда данные и операции "запихиваются в один флакон".
На мой взгляд ФП такая же надстройка но с другим уклоном.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>меня как-то на C# приглашали только потому, что я хаскел знаю. в history of haskell самая понравившшаяся мне фраза — представителя одной из коммереских фирм: "мы обнаружили, что поиск специалистов по хаскелу — это просто способ найти наиболее грамотных и талантливых программистов".
Не потому ли это, что читая введение в Хаскель ближе к середине уши заворачиваются в трубочку, а голова становится деревянной?
Другими словами не кажется ли тебе, что такой способ выявления "широколобых" является отличной демонстрацией отрицательных черт языка?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>интересная мысль. что если ясность можно измерить кол-вом концепций, которые человек должен помнить одномоментно?
Интересный вопрос. К сожалению, чем сожнее задача, тем более выскоуровневыми концепциями нужно оперировать чтьбы описать или понять задачу. Но всему есть предел и иногда количество концепция растет просто в силу сложности задач. Хотя возможно это есть недостаток инструмента и/или проектировщика.
Но однозначно, что чем меньшим объемом надо владеть, тем лучше. Но как говорил, Энштеин — ... но не меньше.
BZ>тогда получится, что функциональный подход выигрывает потому, что вместо нескольких переменных, описывающих обработку, можно ввести одну функцию, которая её осуществляет, к примеру вместо x*a+b ввести функцию f = (+b).(*a) и дальше думать только об "f x"
Это заблуждение. ФП иногда дает хорошие результаты, а иногда не очень. Иногда ООП позволяет описать концепции на очень высоком уровне и тем самым уменьшить количество сущностей которыми надо оперировать.
Мое мнение заключается в том, что ФП, ООП, МП (метапрограммирование), и ЛП (логическое программирование) — это сопособы решения задач которые лучше или хуже подходят в тех или иных случаях. А раз так, то хорошо бы иметь возможность применять их все в рамках одного языка. Да это резко увеличивает набор базовых концепций которыми надо владеть программисту, но это же одновременно позволяет ему выбрать лучшую абстракцию в конкретном случае и уменьшимть то самое количество сущностей в конретной задаче.
BZ>ООП подход выигрывает потому, что вместо набора отдельных процедур, которые осуществоляют обработку данных независимо друг от друга, мы имеем дело с более общей единицей — объектом, и думаём о его поведении в целом
+1
BZ>"обработка волной" в стиле unix и функциональных языков выигрывает потому, что мы каждый раз думаем только об одном промежуточном результате обработки, а не пытаемся рассматривать её глобально целиком. скажем, идиому "sort|uniq|sort" понять куда проще, чем императивную программу, выполняющую все эти действия за раз. юникс ведь потому и стал популярен, что позволил решать задачи обработки текста без создания сложных программ на С
Когда как. Опять же sort|uniq|sort можно записать как sort.()uniq.()sort.() и это будет просто применением процедурного подхода в ООП.
В общем, главное абстракция, а не то где или какими способами она достигается.
Кстати, мой опыт подсказывает мне, что ФП лучше подходит для реализации алгоритмов, а ООП для декомпозиции на уровне прилоежений. Причем объекты могут использоваться в функциональных вычислениях, и наоборот функциональные вычисления могут использоваться для реализации методов объектов. В общем, они взаимодополняют друг-друга, а никак не противоречат друг другу. Просто проблема С++ (C#, Java и т.п.) в том, что эти языки (и их поклонники) обделены фукнциональными средствами (кстати в C# ситуация меняется к лучшему). И проблема Хаскеля (МЛ, Миринды...) в том что эти языки обделены полноценным императивноым программированием и ООП-ом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Короче, прекратим этот спор, т.к. я сомневаюсь что это прокатит в указанных мной случаях. Ты же не имея опыта работы с движками тоже не можешь утверждать. Но все таки я склоняюсь к мнению Cyberaxe здесь
Я имею опыт написания быстрых программ на разных языках. В отличии от вас с Cyberax-ом.
Спор же действительно бессысленнен, так с верой спорить нельзя. А ваша вера в С++ носит чисто реалигиозный характер.
DC>Я не намерен дальше продолжать этот спор. В итоге хочу сказать, что не смотря на все преимущества (более мощную поддержку метапрограммирования) С++ все равно остается неплохим инструментом и не фиг его хаять.
Здравствуйте, BulatZiganshin, Вы писали:
VD>>А зачем интерпретирвемый?
BZ>а зачем мне компилировать шелловские скрипты? скажем, у меня тестирование архиваторов таким скриптом управляется
Вообще-то речь шла о "скриптах" для игр. Они точно ничего похожего со скриптами исполняющимися один раз в сто лет не имеют.
VD>>У ОКамла проблемы с черезмерной строгостью и статиченостью
BZ>в хаскеле это становится проблемой только при динамичсеколй передаче управлени (exceptions) и наверно ещё при динамичсекой подгрузке кода.
Это и есть главная их проблема. Но у ОКамла они еще более явные. Там просто приведение типов или передача ссылок уже проблема.
BZ> в остальном строгость означает только что компилятор сам выведет все типы или скажет, что это совершенно невозможно. у меня было такое, когда я параметром функции ухитрился задать саму эту функцию, и компилятор сказал, что тип входит бесконечным
Ага. Но современный софт не мыслим без динамики. Лично я не буду использовать язык не позволяющий мне создать плагин или исползовать дизайнер форм.
VD>>Компонентность он поддерживает хуже чем С++.
BZ>почему это? в нём даже функторы есть, говорят мощнейшая штука
Фанкторы из другой оперы. Из оперы компонентности CreaeceInstance(строковоеИмяТипа) и приведение типов, скажем к интерфейсам.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, cl-user, Вы писали:
CU>Хм, а на этом "убийце скриптов" можно не перезапускать основную программу после изменения отдельного маленького компонента, а просто указать, что если "скриптик" Х изменился после последней его загрузки — загрузить его заново?
Можно.
CU> И что для этого понадобится включить в эту программу — весь framework языка или маленькую dll-ку интерпретатора?
Можно маленький фрэймвор языка, а не большую длл-ку интерпретатора.
В общем, не надо демагогии. Игры занимают целые ДВД. Многие из них ставят дотент просто ради мелких утилит (вспоминаем хафлайф). Никаких проблем включить в его состав 20 метров рантайма (да хоть сто) нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eugene0, Вы писали:
E>Самообразование — это правильно. Вот только дочитаю вон тот томик по теории алгоритмов, и непременно возьмусь за Немерле. Или за Хаскель. Или еще за что-нибудь
Ясно. С этого надо было и начинать. А то я то его дочитал еще 7 лет назад. И вот пристаю к занятым людям.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>>У ОКамла проблемы с черезмерной строгостью и статиченостью
BZ>>в хаскеле это становится проблемой только при динамичсеколй передаче управлени (exceptions) и наверно ещё при динамичсекой подгрузке кода.
VD>Это и есть главная их проблема. Но у ОКамла они еще более явные. Там просто приведение типов или передача ссылок уже проблема.
ну если динамическая типизация в обработчиках прерываний — главная проблема языка, то он вообще идеален
VD>Ага. Но современный софт не мыслим без динамики. Лично я не буду использовать язык не позволяющий мне создать плагин или исползовать дизайнер форм.
hsplugin есть, есть даже ghc-as-a-library. как это устроено — я не в курсе
при этом они ленивы, но поблочно — каждый блок в 4к символов вычисляется отдельно. так что получается дёшево и сердито плюс они обещают loop fusion, т.е. развёртывание операций типа тех, что я написал, в эффективный императивный код, но я не уверен, что это уже реально работает
BZ>>интересная мысль. что если ясность можно измерить кол-вом концепций, которые человек должен помнить одномоментно?
VD>Интересный вопрос. К сожалению, чем сожнее задача, тем более выскоуровневыми концепциями нужно оперировать чтьбы описать или понять задачу. Но всему есть предел и иногда количество концепция растет просто в силу сложности задач. Хотя возможно это есть недостаток инструмента и/или проектировщика.
ключевое слово здесмь — одномоментно. к примеру, почему советуют разьбивать функции на меньшие? общее кол-во концепций от этого не умеьшится, но в каждой подфункции их остаётся меньше. я специально брал функции с многими обрабатываемыми данными, разюбивал их на части, которым приходилось передавать много аргументов, и программа от этого становилась понятней
ну а дальше в дело вступает системный подход — т.е. ты аккуратно дробишь на каждом уровне концепцию на 7+-2 подконцепций
VD>Это заблуждение. ФП иногда дает хорошие результаты, а иногда не очень. Иногда ООП позволяет описать концепции на очень высоком уровне и тем самым уменьшить количество сущностей которыми надо оперировать.
VD>Кстати, мой опыт подсказывает мне, что ФП лучше подходит для реализации алгоритмов, а ООП для декомпозиции на уровне прилоежений.
ну тогда получается ООД+ФП, верно? надо срочно писать книгу о паттернах ООД+ФП, пока другие место не застолюбили
BZ>>я например вполне поддерживаю Влада в том, что Немерле быстрее хаскела, и в свою очередь языки с нативной компиляцией вероятно быстрее байткодовых
VD>Вобще-то Хаскель как раз компилируется в нэйтив-код. Я ошибаюсь? VD>Байтод же дотнета никогда не исполняется в режиме интерпретации. Он всегда компилируется. VD>Так что если разница есть, то она определяется не байткодом, а другими вещами.
ghc компилируется в натив, однако ленивые вычисления и ужаснейший кодогенератор не дают ему сколь-либо развернуться. а вот если взять ocaml (и даже clean с императивным кодом), то они близки к gcc. что касается байт-кода, то во-первых трудно противостоять таким монстрам, как gcc/icl, а уж тем более трудно это сделать, когда компиляция идёт через промежуточный этап, на котором теряется большая часть семантической информации. далее — языки типа c#/немерле/явы имеют более высокоуровневую модель, которая закономерно выливается в более медленный код. ну к примеру, данные всегда boxed. если же использовать unmanaged расширения этих языков, то никакого выигрыша в лёгкости программирования ты не получаешь
BZ>>вопрос "если наш язык так крут, почему же его никто не использует?" в сообществах small языков возникают куда чаще, чем здесь есть даже статья об этом профессора Вадлера, одного из авторов Haskell и generic Java. если кратко, то дело (помимо объективных свойств самого языка) в *инфораструктуре*: библиотеках, средствах разработки, книгах, обучении и в конечном счёте подготовленных специалистах
VD>Все это действительно влияет на популярность языка. Но разные Вадлеры, на мой взгляд, очень глубого заблуждаютя если считают эти факторы определяющими. Намного важнее интуитивность, привычность и применимость на практике. Так вот языки типа Хаскеля неинтуитивны, непривычны и очень плохохо применимы на практике. А перечисленное тобой — это всего лишь объяснение того почему они не применимы на парктике. Но неинтуитивность и непонятность куда важнее. Но тут уже Валдеры становятся Блаб-ами. Они смотрят на других со своей точки зрения и не хотят принять в рассчет точку зрения других.
VD>С обучением вообще "труба". Все что я пробовал читать по ФП никода не годится. Это писанина сумашедших ученых погрязщих в теоритическом булшите. Их труды скорее способны отбить желание изучать предмет.
VD>Тут нужна литература столь же доступная как труд Кхернигана. Уверен, что успех С во многом определяется его книгой.
мне нечего добавить, кроме того, что "Вадлеров" (это вообще-то самый известный человек в FP) ты обидел незаслуженно я (и не один я, конечно) пишу потихоньку статьи, объясняющие тонкости хаскела, которые я сам успел понять и вообще, весь сайт haskell.org (а он сплощь wikified) — это набор таких статей. сейчас многие мечтают о двух книгах — "advanced haskell" и "haskell in real world" (да, и ещё haskell cookbook), но пока что реальных подвижек в эту сторону не видно. ну а для начинающих литературы достаточно, им не обязательно читать научные статьи. загляни на http://www.haskell.org/haskellwiki/Learning_Haskell
BZ>>людей, способных изучить и эффективно применять какой-нибудь язык, для которого нет хорошо накатанных паттернов, тем более для которого нет отладчиков, библиотек и т.д. -
VD>Вопрос отладчиков, библиотек и IDE очень важен. И его надо решать. Это один из фаторо останавливающих программистов в изучении и применении новых языков. После Дельфи, ИДЕИ и VS 2005 мало кто захочет писать код в нотпэдах или даже в Вимах и Емаксах.
кстати, хорошо что напомнил. Visual Haskell (надстройка над VS) есть. она использует для компиляции ghc, т.е. интеграции во фреймворк нет. но по крайней мере intellisense работает. интерактивный отладчик в ghci уже появился, может через год-два он будет и в VH представлен
кстати, если здесь есть студенты — в google SoC на хаскеле можно заработать также, как и на других языках/проектах
BZ>>меня как-то на C# приглашали только потому, что я хаскел знаю. в history of haskell самая понравившшаяся мне фраза — представителя одной из коммереских фирм: "мы обнаружили, что поиск специалистов по хаскелу — это просто способ найти наиболее грамотных и талантливых программистов".
VD>Не потому ли это, что читая введение в Хаскель ближе к середине уши заворачиваются в трубочку, а голова становится деревянной?
VD>Другими словами не кажется ли тебе, что такой способ выявления "широколобых" является отличной демонстрацией отрицательных черт языка?
разумеется вообще, я бы с удовольствием сам написал введение в хаскел, но не потяну по времени но и в тех книгах, которые есть, за исключением попыток мимоходом объяснить сложные концепции, типа cps и монад, ничего сложного нету. почитай yaht или gentle
Удивительное дело — написал кучу текста, в котором 0 слов относится к предмету разговора. Знаешь как это называется? Врочем, этого и следовало ожидать.
... << RSDN@Home 1.2.0 alpha rev. 673 on Windows Vista 6.0.6000.0>>
Здравствуйте, eao197, Вы писали:
E> Даже переход от процедурного к объектно-ориентированному стилю не требует такого сдвига в способе мышления.
Следует отменить, что переход ООП -> ФП у некоторых индивидов способен
спровоцировать легкий (обратимый) сдвиг по фазе.
а). Отмечаются навязчивые состояния с хаотичными всплесками агрессии.
б). Существенно возрастает мания величия. Индивиду кажется, что он наконец
"прозрел" и очень близко подобрался к "истине".
Раньше такой эффект можно было наблюдать столкнувшись
с индивидом находящимся в процессе изучении LISP, Forth ...
Теперь это сплошь и рядом, особенно после появления Nemerle
(как ни крути, ФП его корневая парадигма).
Здравствуйте, Alexmoon, Вы писали:
A>1. Если он мне нужен для перемещения по памяти занимаемой объектом с более глобальной областью видимости, то о каком освобождении идет речь. Ежели я выделяю под него память и при этом я не имею 100% уверенности что после выделения, до достижения точки присвоения не возникнет исключения, я ставлю перехватчик обязательно в области видимости указателя и как минимум ставлю фильтр на выброс всех описанных спецификацией исключений, алгоритмами выделения. И в зависимости от того где было перехвачено исключение я делаю соответствующие выводы. Все остальное — ошибка программиста, may be. Мог конечно что то и упустить при беглом описании. Не статья, чтобы над ней работать, но суть реализации такова. Я думаю всегда, даже когда знаю что делаю. Это помогает мне не напрягаться отсутствием элементарного внимания в некоторых случаях.
А я в таких случаях использую умные указатели с разрушающим копированием. Типа std::auto_ptr.
Те я просто выделяю память и передаю ее на сохранение такому смартпоинтеру. При помещение в контейнер или возврате из функции владение просто передается. А если будет исключение или что-то другое то память будет освобождена.
ИМХО это гораздо лучше чем постоянно следить за исключениями которые могут появится при будущих рефакторингах.
Обработчики исключений я ставлю только там где могу эти исключения обработать, а не там где выделяю ресурсы. Ибо с ресурсами и смартпоинтеры прекрасно справятся.
Спецификации исключений не использую вобще. Ибо толку никакого, а под ногами путуются.
И вобще если что-то может сделать компилятор то это должен делать компилятор.
Ибо мне нужно задачу решать, а не обработчики исключений для освобождения памяти прописывать.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
D>Следует отменить, что переход ООП -> ФП у некоторых индивидов способен D>спровоцировать легкий (обратимый) сдвиг по фазе. D>а). Отмечаются навязчивые состояния с хаотичными всплесками агрессии. D>б). Существенно возрастает мания величия. Индивиду кажется, что он наконец D>"прозрел" и очень близко подобрался к "истине".
... и тут он кричит "эврика!" и голым выбегает на улицу. способностью делать открытия человек и отличается от животных, isn't?
Здравствуйте, BulatZiganshin, Вы писали:
D>>Следует отменить, что переход ООП -> ФП у некоторых индивидов способен D>>спровоцировать легкий (обратимый) сдвиг по фазе. D>>а). Отмечаются навязчивые состояния с хаотичными всплесками агрессии. D>>б). Существенно возрастает мания величия. Индивиду кажется, что он наконец D>>"прозрел" и очень близко подобрался к "истине".
BZ>... и тут он кричит "эврика!" и голым выбегает на улицу. способностью делать открытия человек и отличается от животных, isn't?
Здравствуйте, Denis2005, Вы писали:
D>Здравствуйте, BulatZiganshin, Вы писали:
D>>>Следует отменить, что переход ООП -> ФП у некоторых индивидов способен D>>>спровоцировать легкий (обратимый) сдвиг по фазе. D>>>а). Отмечаются навязчивые состояния с хаотичными всплесками агрессии. D>>>б). Существенно возрастает мания величия. Индивиду кажется, что он наконец D>>>"прозрел" и очень близко подобрался к "истине".
BZ>>... и тут он кричит "эврика!" и голым выбегает на улицу. способностью делать открытия человек и отличается от животных, isn't?
D>Вы заметили в моем сообщении выделенное слово?
а вы не задумывались, что всё что вы знаете, когда-то было открыто такими "некоторыми" индивидами?
Здравствуйте, BulatZiganshin, Вы писали:
D>>Вы заметили в моем сообщении выделенное слово?
BZ>а вы не задумывались, что всё что вы знаете, когда-то было открыто такими "некоторыми" индивидами?
Это не столь частый случай (оставим историю в покое).
У многих людей процесс познавания чего-то нового протекает спокойно и естественно.
Например, когда я изучал (открывал для себя) ФП посредством языка LISP
(хотя через этот язык я еще много чего познал помимо ФП), то не занимался
его агитацией на каждом углу и регулярными постингами на форумах формата A4,
которые по своей сути содержат смысловую нагрузку не более чем “ФП — это реально круто!”.
BZ>>а вы не задумывались, что всё что вы знаете, когда-то было открыто такими "некоторыми" индивидами?
D>Это не столь частый случай (оставим историю в покое). D>У многих людей процесс познавания чего-то нового протекает спокойно и естественно.
я это привёл для того, чтобы вы *поняли* состояние Влада. ведь понять — значит простить
Здравствуйте, VladD2, Вы писали:
VD>Такие языки как C# или Nemerle с такой задачей справятся великолпно.
Если в своп глубокий не уйдут
VD>Да что там они. Вот погляди: VD>http://www.haskell.org/haskellwiki/Frag VD>это Ку3 написанный на Хаскеле!
VD>А Хаскель — это очень медленно. Кто тебе это сказал?
То есть конечно помедленее чем C++ раза в 2-3, но в целом нормально (лучше чем любой скрипт).
DC>>MC там представлен я не сомневаюсь, только MC не производитель движков.
VD>Да? А кто по твоему MS Flight Simulator делает? VD>А Эдж Оф Эмпаир под чьим крылом? К тому же они делают главную штуковину DirectX, XNA и драверы для видео. Так что они точно знают что нужно разработчикам игр.
Они точно знают что нужно им для того чтобы побольше заработать на разработчиках игр .
P.S. Меня уже давно раздражает что MS пытается быть всем для всех (и ОС, и игры, и офис, и ERP, и КПК, и средства разработки). Куда антимонопольный комитет США смотрит ?
VD>>А Хаскель — это очень медленно. АХ> Кто тебе это сказал?
АХ>Haskell vs C++ АХ>Haskell vs Java
АХ>То есть конечно помедленее чем C++ раза в 2-3, но в целом нормально (лучше чем любой скрипт).
бывает ложь маленькая, ложь большая и бенчмарки
первое — большая часть этих тестов порверяет скорость библиотек, а не генерируемого кода. и при этом стоит ограничение — использовать можно только бибилиотеки, идущие в комплекте с компилятором. BOOST например с gcc не идёт, так что сравниваем мы ежа с ужом
второе — среди этих тестов есть всё же 2-3, проверяющих кодогенерацию. но если посмотреть на реализацию этих задач на хаскеле, то можно увидеть, что они используют императивный никзоуровневый подход, а не ленивые вычисления. или ещё лучше — в библиотеку ghc внесены функции, которые необходимы только для этих тестов. вот более реальные данные:
правда, из них тоже не надо делать вывод, что всё ровно в 700 раз медленней. по моему опыту, на прикладнине можно рассчитывать на падение скорости в 3-10 раз, за счёт того, что используются сишные бибилиотеки, сишные OS calls, и при желании критичную часть кода можно переписать в императивном стиле или на С
ps: и даже тесты, проверяюбщие кодогенерацию, сделаны дубово, поскольку многие из них ограничены скоростью работы памяти! что за бардак...
АХ>P.S. Меня уже давно раздражает что MS пытается быть всем для всех (и ОС, и игры, и офис, и ERP, и КПК, и средства разработки). Куда антимонопольный комитет США смотрит ?
меня лчино это не раздражает, но экономику жалко. монополизм MS имхо тормозит развитие отрасли. например, главная причина выпуска NET, на мой взгляд — стремление привязать разработчиков к одной платформе и отучить их писать переносимый софт, что уже было начало получаться с явой. если бы существовала реальная конкуренция, то уже давно появились бы две-три фирмы с нормальными IDE под яву. а в нынешней ситуации их делать смысла нет
как не трудно догадаться, opengl билиотека, рендерящая всю эту хрень, написана на С. а хаскел выступает в качестве скриптового языка, выдающего ей задания
BZ>как не трудно догадаться, opengl билиотека, рендерящая всю эту хрень, написана на С. а хаскел выступает в качестве скриптового языка, выдающего ей задания
Угу, только случай для современных видео карточек еще более тяжелый, OpenGL для них просто тонкий интерфейс к GPU и практически все выполняется уже аппаратно.
Здравствуйте, eugene0, Вы писали:
E>Вот сайт производителя этого ускорителя E>Только что-то пока ничего особенного с поддержкой этого ускорителя не вышло. E>Во многом потому, что навороченная физика для большинства компьютерных игр довольно сомнительное приобретение.
Здравствуйте, Alexmoon, Вы писали:
A>Вы не являетесь четким определением параметров страшного сна. Забыли и слава богу, для нас. Те индивидуумы, которыми вы соблаговолили назвать и меня до сих пор чудесно справляются с поставленными задачами и с не меньшей эффективностью нежели вы господин.
Откуда такая уверенность в не меньшей эффективности?
A>Я уже сам нервничать начинаю от столь громких заявлений. Все за прохрадительными напитками То что проектирование на ++ требует большего skills — это не значит что это извращение по сравнению с #. Я уже говорил.
Изврашение — это про шаблоны. А про большие skills... С одной стороны имея более мощный инструмент и скилов можно иметь поменьше. С другой, при наличии больших skills и, опять же, более мощного инструмента можно получить более удовлетворительный результат. А у вас получается, выдающиеся skills помноженные на посредственный инструмент = посредственный результат.
A>Каждому свое. Нет не решаемых архитектурных проблем ни с применением ни одного ни другого.
Я уже устал это повторять. Если согнуть руку в кулак, затем распрямить указательный палец и постучать им себя по кости в район лба, то вот там как раз и находится корень зла. Другими словами, это ограниченность наших возможностей. Более мощный инструмент расширяет наши возможности. Запутанный и сложный вынуждает тратить наши усилия на борьбу с этой запутанностью и сложностью.
Есть вещи, которые на плюсах в принципе нельзя сделать без жертв. Если угодно могу привести такой пример регулярно встречающейся задачи, которая в том же шарпе решается исулючительно декларативными средствами.
A>То что вы считаете "так нагло кладет комитет" может быть лишь просто суровой действительностью и если бы он нагло клал, то вы бы и в сторону шаблонов развития никогда бы не увидели.
Вот-вот. Шаблоны были последним достижением, которое случилось более 10 лет назад. С тех пор комитету на всех нас наплевать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Alexmoon, Вы писали:
IT>>Думаю, что для уровня ядра в качестве переносимого высокоуровнего ассемблера лучше подойдёт C, а не C++.
A>Как вы любите цеплятся за определения. Ответьте себе сами. C# еще менее подходит для этого.
Я не предлагаю использовать C# в качестве высокоуровнего ассемблера и не привожу такую возможность языка в качестве аргумента.
IT>>С одной оговоркой. Метопрограммирование на шаблонах — это тупиковая ветвь развития человечества.
A>Сильное определение. Уверенность в себе — это конечно похвально.
Если есть устойчивое желание пообсуждать мои личные качества, то для этого лучше создать отдельный топик и желательно не в этом форуме. Здесь же давай апеллировать не к личности собеседника, а к фактам и здравому смыслу.
A>Но я бы как минимум заменил артикль это на возможно. A>Дальнейший спор не имеет смысла, поскольку он не этого уровня обсуждения. Скажу единственное. Все нужно рассматривать в концепциях языка.
Язык тут вообще не причём. Всё нужно рассматривать в контексте решаемой задачи. Язык — это всего лишь инструмент, станок для выпиливания болванок. Цель — решение задачи. И в этом контексте, C++ для подавляющего числа задач довольно хреновенький станок, который при этом требует высочайшей квалификации обслуживающего персонала. Персонал, конечно же может гордится своей крутизной, но качество и точность выпиливания болванок от этого не увеличивается, т.к. в основном квалификация растрачивается на виртуозность хождения по граблям.
IT>>Мне очень нравится декларативная составляющая современных языков. Не мог бы ты сэмулировать на C++ атрибуты?
A>Мог бы и это не сверхестественное умение. Просто в концепциях языка с точки зрения логики сие выглядело бы совершенно по другому, но если кому так не нравится, или кто то боится ошибится при реализации, тогда смотри выше мое предыдущее сообщение.
Ошибаться при реализации — это неотъемлемая часть нашей работы. Если бы мы все работали по принциапу работы команды Шатла, то нас было бы на несколько порядков меньше, операционные системы вряд ли ещё выползли бы из уровня командной строки и мы бы здесь не общались, т.к. интернет придумали бы только через несколько тысячелетий.
Когда-то по молодости я убил на такую фигню дня три, научился пользоваться отладчиком и вынес несколько полезных уроков.
Бывает, что от написанного кандидатом наук свехинтеллектуального парсера входного потока данных, веб-сервер компании склеивает ласты каждые 30 минут. В связи с ограниченностью времени и запутанностью кода (когда из-за работы с указателями не видно самого алгоритма) переписать это хозяйство на нармальном средстве не получается. В связи с тем, что после исправления выявленных ошибок частота падения сервера становится больше суток, принимается решение о перегрузе сервера раз в сутки в момент наименьшей активности пользователей. Problem solved!
А бывает, что таких ошибок не бывает в принципе. Ошибки, конечно же, остаются. Но это другого уровня ошибки. Такие ошибки очень быстро выявляются и ещё быстрее фиксятся. А раз так, то про "кто то боится ошибится при реализации" вообще не стоит речи. Я как раз боялся ошибится, когда писал на плюсах. Сейчас для меня эта тема не актуальна.
A>Два раза одно и то же я не повторяю. Мы не дети. Давайте без нравится, а то я напишу что мне нравится Jennifer Lopes.
IT>>Ничего логичного и естетсвенного. Метапрограммирование на шаблонах — это высокоинтеллектуальное извращение. А извращение не может быть естественным. Даже высокоинтеллектуальное. A>Ничего общего с тем что вы определили не имеет. То что в вашем понимании извращение, может таковым совершенно не являтся, но в концепциях С# конечно такой гибкости нет, поэтому можно и таким аттрибутом по умолчанию наградить. Давайте озаглавливать контексты "Я так думаю", и наче обсуждение обречено.
Не надо ничего никуда озаглавливать. Я не думаю, я знаю. Моя первая строчка кода на C была написана где-то в 89 году. Последняя на плюсах в 2003 (C++/CLI не в счёт). Я хорошо знаю этот язык и знаю его возможности. Кроме этого я пишу на языках отличных от плюсов и так же знаю и их возможности. Так вот. Метапрограммирование на шаблонах — это высокоинтеллектуальное извращение. Даже emit при примерно тех же затратах делает шаблоны как два пальца об асфальт. А если взять языки, специально заточенные на метапрограммирование, то шаблоны C++ — это даже не 1-й класс вторая четверть, это детский сад ясельная группа. Сначала с горшка научитесь самостоятельно вставать и попку подтирать, а уже потом будете задавать свои глупые вопросы большому дяденьке.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, WolfHound, Вы писали:
WH>А я в таких случаях использую умные указатели с разрушающим копированием. Типа std::auto_ptr. WH>Те я просто выделяю память и передаю ее на сохранение такому смартпоинтеру. При помещение в контейнер или возврате из функции владение просто передается. А если будет исключение или что-то другое то память будет освобождена.
Мне это зачем рассказывать? Я прекрасно все это знаю, хоть и не всегда использую. Мно и то чем я пользуюсь совершенно прозрачно, а если структура такова что я боюсь потеряться, то использую и это. Если вы хотели донести не только мне эту информацию, то она не сюда. Кому она здесь полезна или это влияет на эффективность? На мою нет. Мне все равно как это организовать, если я прозрачно понимаю суть работы механизма.
WH>ИМХО это гораздо лучше чем постоянно следить за исключениями которые могут появится при будущих рефакторингах.
ИМХО это все равно если рефакторинг не делается с бодуна и архитектура сделана вминяемой. Или это самая главная проблема, которая является камнем преткновения, чтобы отдельно выводить в контексте данного обсуждения.
WH>Обработчики исключений я ставлю только там где могу эти исключения обработать, а не там где выделяю ресурсы. Ибо с ресурсами и смартпоинтеры прекрасно справятся.
А какова вообще проблема справиться с ресурсами, когда деструктор объекта будет надежно вызван?
WH>Спецификации исключений не использую вобще. Ибо толку никакого, а под ногами путуются.
Я так понимаю, что мне где то здесь тоже нужно чего нибудь интересного рассказать, чтобы не поняли превратно, что я отвечаю только "ДА" либо "НЕТ".
Толку действительно никакого, но есть еще и супер спецэффект той обретки, которую строит компилятор вокруг спецификации. При выбрасывании исключения при наличии спецификации проверяется его тип, и если он не подходит не под одно из описаний, согласно стандарту, тогда программа завершается аварийно, даже при наличии перехватчика данного исключения выше по стеку.
Скептики сейчас просто ощутят прилив адреналина, но зря. На параметр эффективность это никак не влияет, для того кто знает что делает.
Я это лишь к тому что даже это я считаю должным знать. Чем более гибкий инструмент ты используешь, тем больше должна быть тяга к знаниям, поскольку чем больше возможностей, тем долее сложна дорога к совершенству.
WH>И вобще если что-то может сделать компилятор то это должен делать компилятор. WH>Ибо мне нужно задачу решать, а не обработчики исключений для освобождения памяти прописывать.
На любые утверждения найдутся вопросы.
Что может и что должен решать компилятор? Как критерий уровня тех, для кого он должен решать все, а для кого не все? Как это определяет то, что одно заменяет другое, а не просто его дополняет?
Это уже не к вам относится, но тут впору вступить тем кто вообще не касается программирования. А почему для них компилятор не решает многих вопросов? И должен ли он это делать?
Какую задачу вам нужно решать? Зарабатывать как можно больше денег, при этом не напрягаясь вообще, тогда как минимум сложно определить степень того, что лично вам должен компилятор, а что мне, а что еще кому то. Где есть список требований?
Если нет, тогда какие претензии к каклму либо конкретному языку, инструменту и т.д.?
A>Какую задачу вам нужно решать? Зарабатывать как можно больше денег, при этом не напрягаясь вообще, тогда как минимум сложно определить степень того, что лично вам должен компилятор, а что мне, а что еще кому то. Где есть список требований?
компилятор должен делать сложные задачи простыми, а не наоборот
Здравствуйте, VladD2, Вы писали:
VD>Это видно не вооруженным взглядом. Может ты и знаешь еще с сотню менее мощьных языков (однотипных), но сути дела это не меняет. Твое явное непонимание того что тебе высказывают говорит само за себя. Обижаться тут бессиленно. Надо или преркащать идсскуюссию и оставаться в блаженном неведении или все же попытаться изучить альтернативы и вести разговор используя общие понятия.
В пору поклониться вам духовный учитель. Скажу вам искренне, если способны что либо не предвязто воспринимать. За слова извините. Спуститесь с небес и перечитайте то что вы сверху написали и правильно ли вы цитировали в памяти, что я хотел донести и каких именно определений касались высказывания. Ваши выводы столь же безосновательны, как и ваше не желание вдуматься в то что я не оправдывал повсеместного использования того, что на оное не претендует, а лишь высказывал свое несогласие с тем, что вы совершенно безосновательно хаете то, что возможно и заслуживает этого но как минимум вам было указано на собственные заблуждения. Я надеюсь вам тоже бессмысленно обижаться, если вы трезво мыслете.
1. Тому кто хочет оставаться в блаженном неведении вообще в эту ветвь не заглядывал.
2. Не только пытаемся, но и изучаем, как бы странно вам это не казалось.
3. Из всего того что было сказано вами выше, общих понятий для обсуждения менее 10% процентов.
4. Если более, то это значит лишь то, что в моих словах не более пустословия, чем вы не готовы воспринимать что либо кроме своеог собственного мнения.
Кто то выше пытался привязаться к моим конкретным утверждениям, но почему то великих это не касается. И на это и на то я не обижаюсь, иначе я бы на это точно не ответил и на половину того, что пытался донести выше.
Вам никогда не казалось то, что ваш вооруженный взгляд ошибается? Если ответите да, то я об этом не узнаю, а если нет, то ответ не верен, и врядли что либо изменит.
Здравствуйте, VladD2, Вы писали:
VD>С обучением вообще "труба". Все что я пробовал читать по ФП никода не годится. Это писанина сумашедших ученых погрязщих в теоритическом булшите. Их труды скорее способны отбить желание изучать предмет. VD>Тут нужна литература столь же доступная как труд Кхернигана. Уверен, что успех С во многом определяется его книгой.
Жаль нету оценки +10 В смысле 10 раз согласен..
Многие введения в ФП расчитаны на математиков. Хотя многие вещи можно объяснить намного проще.
Да чего далеко ходить. На днях скачал книгу "Лямбда счисление". Автор Х. Барендгерт.
В указаниях читалелю есть раздел требуемая подготовка
Эта книга по существу не требует предварительной подготовки. Лишь временами нужны элементарные знания из логики первого порядка, топологии, теории множеств, теории рекурсии и теории категорий ...
и список на полтора десятка книг ...
В предисловии к русскому изданию цитата
Книга ... — первое на русском языке подробное и доступное изложение лямбда счисления.
Я боюсь себе представить "недоступное" изложение
Но тем не менее имеются тенденции к исправлению ситуации. Что не может меня не радовать. Хочеться верить что "весь этот горький катаклизм который мы здесь наблюдаем" (с) не будет вечным.
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Здравствуйте, BulatZiganshin, Вы писали:
BZ> я бы с удовольствием сам написал введение в хаскел, но не потяну по времени
Хочется надеятся что время когда-нибудь все же найдется
BZ>но и в тех книгах, которые есть, за исключением попыток мимоходом объяснить сложные концепции, типа cps и монад, BZ>почитай yaht
Если из yaht выкинуть упоминание о монадах и о cps то его объем уменьшится на 40 страниц. При общем объеме tutorial-а в 190 страниц. Имхо из-за таких "мимоходных" вставок вместо нормального человеческого объяснения и возникает куча проблем с пониманием.
BZ>или gentle
А gentle в качестве введения имхо слишком краток. Конечно если у человека есть понимае общих идей применяемых в Хаскеле как то pattern matching, partial application etc. То по gentle можно еще в каком-то виде. Но по gentle пытаться понять указанные концепции —
Вообще это все брюзжание производится в надежде что если вдруг будет писаться очередное введение в Хаскел то пожелания будут учитываться
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Здравствуйте, VladD2, Вы писали:
VD>Хлопать тоже не надо. Просто твои предположения не верны. Я писал на С++ 10 лет. Правда тогда еще шаблоны были по слабее (в начале их вообще не было), и СТЛ мы не использовали так как он появился после того как мы сделали свои библиотеки, но это мелочи. Вольфхаунд и сейчас зарабатывает хлеб программированием на С++ просто потму что за него сейчас платят хорошо. И он уж точно на современных выкрутасах С++ не одну собаку съел. VD>В общем, ты лучше спроси. А то видишь, что люди что-то критикуют и сразу строишь предположения о низкой компетенции в этой области.
Люди могут критиковать что либо, но это не значит что они в своей критике объективны абсолютно. Наверное меня тоже не хотели понять, раз так плохо сложился вывод об опыте.
VD>Твой опыт однобог. Это я вижу очень четко. Ты узкий специалист, о которых говорил Козма Прутков. И вместо того чтобы спросить о чем мы ведем речь и проинализировать эти слова, ты сразу делаешь выводы на основании своего опыта. Это не констрктивно. Это все равно что закрыть глаза перед акулой и представить что ее нет. Может так и спокойней, но спокойствие это илюзорно.
Вывод неправильный и поэтому спор имеет тупиковое направление.
VD>К сожалению совершенству мира мешают такие человеческие грехи как косность, посредственность, лень, трусость, неумение менять привычки. Одни боятся изучать новое. Другим лень. Третьи просто не способны на это интеллектуально. Четвертым все до лампочки. Пятые так привыкли к убогости, что не могут даже представить как жить по другому. И т.д, и т.п.
VD>Вот, ты наприммер, за все время полемики даже не разу не удосужился уточнить "А что же мы предлагмем взамен?". Видимо не интересно. Ведь ты уже в этой жизни для себя все решил. Есть правильный путь, и он тебе звестен. Я угодал?
Нет, не угодал. Не решил и не собираюсь ставить точку. Вот только насколько актуальна ваша замена, вас инересует только в контексте ваших мыслей. Я угадал. Вы говорите то все правильно, но не всегда объективны.
VD>Представь себе идеомы бывают более и менее удачными. А бывает так, что что-то новое полностью поддерживает идиомы старых решений и предлагают кое-что нове. Или поддерживает идиому более чистым образом. Ну скажем, поддерживает метапрограммирование напрямую, без александревсовских ухищрений.
А есть такое? И при этом это что-то полностью сводит эффективность испольования чего то к нулю?
Не в ваших словах было аггресивное безальтернативное заявление? Мне не показалось это вопросительным, как запрос к обсуждению. Вы уже все решили, и при этом мнение других заведомая ошибка?
VD>А что же нелогичного в том, что нас что-то не устраивает? Может быть мы знаем как можно делать тоже самое, но лучше?
Кто знает как делать лучше? Я так понимаю, готов список фамилий. И пожалуйста вдумайтесь глубже в мои слова глубже чем вам могло бы показаться. Это не утверждение обратного, а лишь вам знак того, что так же полностью объективны и восприимчивы к тому на что отвечают, а не ищите подвох в словах.
VD>Не. Это конечно не проблемы комитета. Ему просто по барабану. Это вообщене человек. У него нет единого мнения. Да и язык от тупого животного по имени комитет не помрет сразу. Он будет медленно деградировать или просто остановится в развитии.
Вы никогда не воспримите актуально суть происходящих вещей, отличных от вашего мнения. Я это тоже прозрачно понимаю не вооруженным взглядом.
VD>Да, уж. Не поспоришь. Один факт не отрицает гипотетической возможнсоти наличия дугого. VD>Но первый факт остается фактом.
Вопрос лишь в том, к какому разряд вы его определили.
M>Эта книга по существу не требует предварительной подготовки. Лишь временами нужны элементарные знания из логики первого порядка, топологии, теории множеств, теории рекурсии и теории категорий ...
буду цитировать
M>
M>Книга ... — первое на русском языке подробное и доступное изложение лямбда счисления.
M>Я боюсь себе представить "недоступное" изложение
разные народы издали книги о слонах. русские "россия — родина слонов". немцы — 3х-томник "введение в науку о слонах". американцы — покетбук "всё, что нужно знать среднему американцу о слонах"
вообще, имхо вы всё не то читаете. зачем лямбда-исчисление, ТК и прочая теория? нет, если интересно, то это пожалуйста, но причём тут освоение хаскела? есть же страница learning haskell, на ней всё полезное добро перечислено. если есть возможность — лучше купить одну из книг из радела 2.1, они как я понимаю на более высоком уровне написаны, кадровыми профессорами, а не самоделкиными, как этот yaht
у меня есть preview одной книги (вышежшей кстати буквально месяц назад) — могу его намылить. это не вся книга, только где-то половина, но я его кратко проглядел — вроде очень доступно описано
ну а если хаскел по таким книгам кажется слишком простым языком — так и слава богу. начинайте программировать, какие дальше требуются темы — спрашивайте и мы подскажем, что дальше рыть. но по большому счёту, все неэлементарные вещи описаны в научных статьях
Здравствуйте, VladD2, Вы писали:
VD>ОК, тогда тебе не составит труда описать известные тебе языки с встроенными возможностями метапрограммирвоания объяснить почему ты считашь, что С++-ное метапрограммирвоание на шаблонах лучше, или хотя бы не хуже. Не составит?
Не составит конечно, но раз так встал вопрос, тогда открою тебе глаза. Я лично, не считаю С++-ное метапрограммирование лучше языков со встроенными возможностями. Я лишь пытался высказать свои мысли по поводу, почему оно в ++ пока встроенно только на базе шаблонов. Если вы этого непоняли, тогда все ваши предыдущие выводы невооруженным взглядом неверны двже без оговорок.
К какой объективности вы призываете меня, хотя согласие с чем либо у вас возникнет, только при условии полного соответствия вашим шаблонам мышления. Это видно моим не вооруженным взглядом. Обижаться ту нечего.
Я вам на любой вопрос отвечу, вот только вам это не поможет, и не нужно делать выводы относительно эффективности опыта того, кого вы совершенно не знаете и тем более сравнивать с чем либо вам известным, с заранее заготовленным результатом. WolfHound молодец. Попытался, выше постами или ниже, не помню, да и не важно, поделиться со мной опытом в области С++. Но как оказалось данный опыт уже есть. Я конечно не сомневаюсь что где либо мы не пересечемся, но точно знаю что признак эквивалентности будет близок.
Вы немного подумайте перед тем как отвечать, если у вас время для сна еще осталось.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>вообще, имхо вы всё не то читаете. зачем лямбда-исчисление, ТК и прочая теория? нет, если интересно, то это пожалуйста, но причём тут освоение хаскела?
Лямбды как раз к хаскелю не причем. Это я для себя, для общего тыкскзть развития, равно как и ТК. Просто большинство туториалов по монадам у меня вызывали похожие чувства. Ну не было ни кого кто сказал бы, что next level это совсем даже и не монады, а type classes или еще чего
BZ>есть же страница learning haskell,
А более конкретно ссылку можно? А то гугл выдает несколько страниц, но ни на одной раздела 2.1 я что-то не увидел
BZ>у меня есть preview одной книги (вышежшей кстати буквально месяц назад) — могу его намылить.
Если не сложно, на мыло в профиле плз.
BZ>но по большому счёту, все неэлементарные вещи описаны в научных статьях
Вот вот. Лучше бы все же была возможность выбора "слоны для среднестатистического американца" или "Россия родина слонов" или "Элементарное введение в слонологию в 4-х томах". Но когда начинаешь копать находишь только материалы "не требующие предварительной подготовки" (с).
С императивным программированием и ООП выбор гораздо шире. От "ООП для совсем тупых домохозяек" до Александреску. Эхх..
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Здравствуйте, AndrewVK, Вы писали:
AVK>Удивительное дело — написал кучу текста, в котором 0 слов относится к предмету разговора. Знаешь как это называется? Врочем, этого и следовало ожидать.
Мне в каждом ответе не упускать предмет разговора или в твоем вопросе было что более касающееся предмета, что тебе что-то известно. Как называется?
Чтобы не следовало ожидать, тогда задавая вопрос, а не комментируя ошбочные выводы, пожалуйста список вопросов. Я в 10-ый и последний раз говорю, что то следовало вами ожидать совершенно не касается того, что я конкретно хотел объяснить. Вы все прочитали и если что либо было не понятно, тогда обратитесь к Vlad2. Он все, по его мнению кристально понял, хоть и не пытался этого сделать. А вы на его аргументы почему то глаза напрочь закрыли, хотя они по моему после 50-го или 60-го уже никакого отношения к началу обсуждения не имеют.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>у меня есть preview одной книги (вышежшей кстати буквально месяц назад) — могу его намылить. это не вся книга, только где-то половина, но я его кратко проглядел — вроде очень доступно описано
Здравствуйте, IT, Вы писали:
IT>Не надо ничего никуда озаглавливать. Я не думаю, я знаю. Моя первая строчка кода на C была написана где-то в 89 году. Последняя на плюсах в 2003 (C++/CLI не в счёт). Я хорошо знаю этот язык и знаю его возможности. Кроме этого я пишу на языках отличных от плюсов и так же знаю и их возможности. Так вот. Метапрограммирование на шаблонах — это высокоинтеллектуальное извращение. Даже emit при примерно тех же затратах делает шаблоны как два пальца об асфальт. А если взять языки, специально заточенные на метапрограммирование, то шаблоны C++ — это даже не 1-й класс вторая четверть, это детский сад ясельная группа. Сначала с горшка научитесь самостоятельно вставать и попку подтирать, а уже потом будете задавать свои глупые вопросы большому дяденьке.
Вот теперь все понятно. Я свою первую строчку написал на ++ в 92 или 93 и поэтому просто иду подтирать попку. Аргументов немного но все в точку.
Здравствуйте, jazzer, Вы писали:
J>Кстати, вот была такая игра — "Казаки" (реал-тайм стратегия, отличается тем, что может держать одновременно на игровом поле 16т юнитов (первая версия, сейчас до 64т дошли, по-моему, не помню). Конкурентам такие цифры и не снились. Имхо, одна из лучших отечественных игр.
J>Я всего ее кода не видел, только маленький кусок, но что я увидел там: она была написала на С++, и более того, стратегии AI для игры за разные страны (там у разных стран разные строения, оружие, стоимость ресурсов и прочее, поэтому по-разному надо действовать) были тоже написаны на С++ и упрятаны в DLL-ки с названиями стран (т.е. если ты хотел играть против, скажем, Австрии, то просто подгружалась соответствующая DLL-ка и начинала против тебя играть). На моей тогдашней слабенькой машинке все летало.
Игрухи для мальчишек и девчонок, а также их родителей мне писать не довелось, но игрушки для военных писать приходилось. В частности делались имитационные модели боя для оценки комплектов вооружений. Число объектов в таких моделях легко достигало 150-ти тысяч. Дело было десять лет назад и писалось всё естественно на плюсах кроме одного НО. Для описания столь сложных моделей использовался язык декларативного описания моделей, специализированный DSL, на написание и доводку которого ушло пару лет. Вот в таком тандеме плюсы рулили. Тем не менее сегодня существуют языки, которые способны решать не менее эффективно весь комплекс проблем. При этом два года на написание компилятора и движка моделей точно не понадобится.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
M>Лямбды как раз к хаскелю не причем. Это я для себя, для общего тыкскзть развития, равно как и ТК. Просто большинство туториалов по монадам у меня вызывали похожие чувства. Ну не было ни кого кто сказал бы, что next level это совсем даже и не монады, а type classes или еще чего
надо было в cafe спросить
BZ>>есть же страница learning haskell, M>А более конкретно ссылку можно? А то гугл выдает несколько страниц, но ни на одной раздела 2.1 я что-то не увидел
BZ>>но по большому счёту, все неэлементарные вещи описаны в научных статьях M>Вот вот. Лучше бы все же была возможность выбора "слоны для среднестатистического американца" или "Россия родина слонов" или "Элементарное введение в слонологию в 4-х томах". Но когда начинаешь копать находишь только материалы "не требующие предварительной подготовки" (с). M>С императивным программированием и ООП выбор гораздо шире. От "ООП для совсем тупых домохозяек" до Александреску. Эхх..
просто некому пока писать. я вот вас здесь сагитирую, гдядишь — кто-нибуль и напишет
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>у меня есть preview одной книги (вышежшей кстати буквально месяц назад) — могу его намылить. это не вся книга, только где-то половина, но я его кратко проглядел — вроде очень доступно описано
EC>Не "Hutton A. — Programming in Haskell" часом?
да конечно. не так уж и много книг по нему выходит
Здравствуйте, Alexmoon, Вы писали:
A>Вот теперь все понятно. Я свою первую строчку написал на ++ в 92 или 93 и поэтому просто иду подтирать попку. Аргументов немного но все в точку.
А ты тут при чём? Я же не о тебе говорю, а о метапрограммировании на плюсах
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, BulatZiganshin, Вы писали:
EC>>Не "Hutton A. — Programming in Haskell" часом? BZ>да конечно. не так уж и много книг по нему выходит
Не сказал бы что хорошая книга, доступность-доступностью, но стиль изложения в виде "это просто надо запомнить" наводит тоску. А последние главы вообще смазаны и "предполагается очевидность".
В принципе, если читать как введение в язык до чтения всяческих Tutorials — то вполне пойдёт, а если заставить себя выполнять упражнения, то наверное ещё и эффект понимания будет (кстати стиль чем-то SICP напоминает).
Если же требуется глубина понимания основных концепций, то это явно не та книга
(Хотя у меня вообще какой-то драфт от 2005 года).
Здравствуйте, BulatZiganshin, Вы писали:
BZ>у меня знакомый весной купил машину с гигом. осенью его спрашивают, он говорит — у меня два гига. думаю, дело в том, что у него осталось смутное впечатление "у меня памяти ого-го сколько!", а по осени гиг за ого-го уже не канал
Многим новым играм одного гигабайта уже откровенно не хватает.
Здравствуйте, eugene0, Вы писали:
CC>>Не столько сложен, сколько сыроват. Работал с Havok 2 — тот гораздо стабильнее. Впрочем и в нем тогда с ragdoll была проблема, которую даже с их саппортом решить не удалось. E>Хавок денег стоит, насколько мне известно. Нам их не дадут
Сильно
... << RSDN@Home 1.2.0 alpha rev. 673 on Windows Vista 6.0.6000.0>>
AndrewVK wrote: > CC>>Не столько сложен, сколько сыроват. Работал с Havok 2 — тот гораздо > стабильнее. Впрочем и в нем тогда с ragdoll была проблема, которую даже > с их саппортом решить не удалось. > E>Хавок денег стоит, насколько мне известно. Нам их не дадут > Сильно
Он действительно стоит достаточно больших денег, да еще и требует
процент с прибыли от игры. Не для всех это будут достаточно приемлимые
условия.
Здравствуйте, Andir, Вы писали:
A>Не сказал бы что хорошая книга, доступность-доступностью, но стиль изложения в виде "это просто надо запомнить" наводит тоску. А последние главы вообще смазаны и "предполагается очевидность".
О, очень интересно. А можно приблизительный пример — "это надо запомнить" изложения и как бы это хотелось видеть? Это не для флейма, это для меня.
Имеется в виду, что нет объяснения причин появления такого решения, или речь о чём то ещё?
A>В принципе, если читать как введение в язык до чтения всяческих Tutorials — то вполне пойдёт, а если заставить себя выполнять упражнения, то наверное ещё и эффект понимания будет (кстати стиль чем-то SICP напоминает).
Ещё интересный момент. Ну это ко всем вопрос — считаете ли вы, что упражнения — это всегда хорошо, если нет, то в каких случаях нет.
Здравствуйте, lomeo, Вы писали:
L> Ну это ко всем вопрос — считаете ли вы, что упражнения — это всегда хорошо, если нет, то в каких случаях нет.
Я считаю что для книг обучающих упражнения обязательно должны быть. Причем чем больше, тем лучше. И желательно с ответами. И с подробными объясненями хотя бы части ответов. А не просто "42".
L>О, очень интересно. А можно приблизительный пример — "это надо запомнить" изложения и как бы это хотелось видеть? Это не для флейма, это для меня.
можешь посмотреть саму книгу, точнее то её превью, которое мы скачали. тем не менее, я продолжаюю поагать, что книги Худака и прочих основоположников лучше работы Хал-Ван Дама и сделаны в более педагогическом стиле
L>Ещё интересный момент. Ну это ко всем вопрос — считаете ли вы, что упражнения — это всегда хорошо, если нет, то в каких случаях нет.
человек учится только на практике. поэтому мой педагогический талант подсказывает мне, что каждое излагаемое теоретичсекое положение надо илдлюстрировать конкретными примерами, и добавлять задания для самостоятельного решения. кстати, одна из книг там сделана именно в таком ключе — [http://www.cs.ou.edu/cs1323h/textbook/twoDzn.zip]
Здравствуйте, Alexmoon, Вы писали:
A>Я вам на любой вопрос отвечу, вот только вам это не поможет, и не нужно делать выводы относительно эффективности опыта того, кого вы совершенно не знаете и тем более сравнивать с чем либо вам известным, с заранее заготовленным результатом. WolfHound молодец. Попытался, выше постами или ниже, не помню, да и не важно, поделиться со мной опытом в области С++. Но как оказалось данный опыт уже есть. Я конечно не сомневаюсь что где либо мы не пересечемся, но точно знаю что признак эквивалентности будет близок.
Вот только не нужно меня сюда приплетать.
Ибо главное что я пытался тебе сказать до тебя не дошло.
Я пытался это сказать и намеками и прямым текстом но...
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Итак, опять ничего по делу. Я так понимаю, это манера вести спор такая? Не советую, здесь есть люди, намного лучше тебя владеющие демагогией.
Да, Андрей. Твоя среднепотолочная сравнительно-оценочная характеристика потрясает воображение. Чтобы не было заблуждений, скажу сразу, что я даже несомневаюсь, что где угодно есть люди владеющие демагогией на порядок лучше меня. Вот это как раз никогда заблуждением не было. Но все равно спасибо, что напомнил. Если ты хочешь дать человеку понять свое место, по другому это не назовешь, если это не изощренный юмор, который я тоже могу понять, тогда количества агрументов более чем.
Этот абзац, говорю сразу, представляет небольшую порцию Undocumented speech, в котором поиск аргументов, для оптимизации алгоритма, лучше упуститть. История нашего с тобой локального обмена фразами напоминает мне один вариант:
Final State Machine у которой в определенном состоянии в таблице переходов все классы символов приводят к переходу в то же состояние и наверное я уже точно не смогу найти ключ к продолжению восприятия информации, ежели кто либо не владеет доступом к методам аварийного перехода.
С тобой в компании не скучно. Это даже я способен понять, раз уж ты меня определил парой вопросов, как это называется и что за манера. Всегда приятно поговорить с умным человеком. Искренне уважаю и это не шутка.
У нас в команде есть один человек, даже не важно кто и нельзя ему отказать в компетентности, который если начинает нервничать, то все просто закрывают двери и говорят. Он нервничает. Лучше его не трогать, а то сейчас на доске начнет рисовать. Это лишь его особенность, хотя он и сам понимает, что не всегда абсолютно прав, но такой способ выговориться — это аттрибут. Главное лишь то, что он в обществе, которое его правильно воспринимает.
Ты ждешь от меня ответов на вопросы? Тебе с удовольствием отвечу.
"Я дурак", наверное в приличном обществе неприемлемо, и поэтому заканчивая разговор завершаю ожидаемым результатов.
Я — человек прибывающий в полном невединии и вопиющем заблуждении. Демагог-неудачник. Один плюс — с хорошим чувством юмора. Надеюсь вы не затопчете меня за это и отнесетесь с пониманием. Может хоть этого уровн развития мы наконец достигли.
Умолять меня может только одно, что это никак не влияет на развитие моего кругозора и эффективности работы. Это мне просто необходимо, ежели я человек думающий. Извините меня за утверждение, не подтвержденное вами.
Искренне прошу, ежели Мил Сир будет столь любезен, все таки дать определения того "Как это называется?" и "Как называется такая манера вести разговор?". Хоть по данной части я буду полностью осведомлен.
У меня все. Похоже что в данном обсуждении цель была не понять моих мыслей, а найти опровержение собственных. Наверное я неправильно воспринялсуть происходящего и здесь утверждения излишни, если они не несут в себе вопроса. Возвращаюсь в школу.
С уважением ко всем участникам проекта RSDN, Александр.
Здравствуйте, Last Cjow Rhrr, Вы писали:
LCR>И да, и нет. У меня есть два аргумента за:
LCR>1. Человек ушёл с одного проекта на Java, который он писал где-то года 2. Парень, который пришёл на замену, провёл 10 месяцев, прежде чем написал первую строчку своего кода!!!
В смысле нового кода?
LCR>Меня просто ужас охватывал, когда он мне показывал список классов — он просто нажимает скроллинг и держал. А классы бежали и бежали. От имён уже начинало рябить в глазах, и наконец они сливались в одно непрерывное полотно, и лишь отпечатывался префикс C* или I*...
А сколько кода-то? Да и вообще чтобы один человек столько нагенерировал?
LCR> По сравнению со сроком изучения системы, изучение языка это просто "о малое".
А что у вас за безумный проект такой? А документации, что, нет?
Я вот сейчас работаю с С++ библиотекой в которой порядка 800000 строк и 2200 классов, но в принципе с более-менее нормальной документацией (doxygen-сгенерированная + примеры), и навигацией по исходникам и как-то получается сразу .
LCR>2. Потом люди, которых я знаю по жизни и в сети, с радостью бы работали на Хаскеле, дай им такую возможность. Да блин, я хоть сейчас, и даже на меньшие деньги. То есть я думаю, такие люди есть везде. Но! Найти действительно шарящего парня, которому не страшно доверить самые ответственные участки — это проблема. А как только мы его нашли, то изучить для него хоть Хаскель, хоть J, хоть N — не проблема.
LCR>Так что с позиции руководителя — 100% согласен, но с позиции практикующего программиста — только 20%
По-моему, наоборот, это программисту интереснее новые решения, эксперименты, креатив, а руководителю нужно чтобы программист просто работал как часы на стандартных технологиях и его легко можно было заменить если надо.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, eao197, Вы писали:
E>>Так что я сейчас более склонен поменять C++ не на сложный Haskell, а на что-нибудь гораздо более простое. Вроде пятого Турбо Паскаля или Oberon-а Бертран Мейер, редиска, Eiffel за деньги продает
FR> FR>Кстати D если запретить шаблоны тоже хороший вариант как простой язык.
+1
P.S. Правда тут Александреску на днях обещал макросы добавить в D помимо шаблонов и миксинов. Вот тогда заживем .
Здравствуйте, WolfHound, Вы писали:
WH>Вот только не нужно меня сюда приплетать. WH>Ибо главное что я пытался тебе сказать до тебя не дошло. WH>Я пытался это сказать и намеками и прямым текстом но...
Извини. Использование имени при том, что я ничего не хотел сказать плохого по поводу твоего примера, не совсем правильно.
Но что?
1. Ты рассказал мне совершенно очевидную вещь. Тем более что я с ней всегда был согласен.
2. Я всегда был согласен с тем что использование сырых указателей, таит в себе скрытые утечки.
3. Ты хотел мне сказать о том, что давно пора было внести в язык соответствующие коррективы?
4. Возможно.
5. Ты приведи мне то мое цитирование, лучше ссылкой, которое ты хотел мне опровергнуть своим примером.
6. Не выдирай пожалуйста из контекста отдельные фразы, которые по отдельности можно совершенно по разному трактовать.
7. Тогда и мне проще будет тебе разъяснить суть, того что я имел ввиду, а не то что ты понял. Это не даст мне возможности тебя обвинить в полном не понимании моих определений.
Я тебя полностью понимаю, но ты даже не пытаешся понять меня. Давай не будем ставить наш опыт себе в минус, определяя для себя что наши мнения абсолютны. Я этого недостатка лишен, а вот ты, не буду утверждать. не знаю.
Сейчас получается картина, которую можно описать фразой. Ты тренеруешся мне доказывать правильность своего подхода, а я тебе своего, не смотря на то что они оба имеют место. Возможно даже об одном и том же, но при этом никто из нас не пытаетс слышать друг друга, а лишь ждет ответа на свои фразы "ОК. ГОДИТСЯ."
Что я не так понял? Или какое мое утверждение, ссылкой пожалуйста, ты пытался опровергнуть. Не нужно излишними намеками искжать смысл. После 10-го раза это полностью меняет смысл понимания утверждаемого.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>P.S. Правда тут Александреску на днях обещал макросы добавить в D помимо шаблонов и миксинов. Вот тогда заживем .
Самое смешное в этом то, что ни Александреску, ни Брайт пока сами не знают, что же это будет за макро система такая. Об этом Брайт где-то прямым текстом заявил (я читаю digitalmars.D через Opera, поэтому не могу дать точную ссылку на новость через Web-интерфейс).
Более того, сейчас народ пытается разобраться, что с новыми mixin-ами реально можно делать и как бы сделать так, чтобы не было отдельного compile time D (для обработки текстовых миксинов) и отдельного run-time D. К Александреску пристали, чтобы он хоть какие-то реальные примеры привел из того, что он хочет иметь. Он смог представить только пример с black и white box имплементацией интерфейсов для тестовых целей. За что на него даже наехали, мол люди пытаются на D реальные задачи решать, а вы здесь какими-то теоритическими изысканиями занимаетесь.
Причем люди стали приводить весьма нетривиальные примеры DSL-ей, для обработки которых возможностей шаблонов и static if, на мой взгляд, явно не хватит. Что интересно, Брайт пока молчит. Может быть задем каким-нибудь оригинальным решением разродится -- вроде плагинов к компилятору, которые будут заниматься compile-time обработкой DSL.
В общем, интересный момент в истории
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>можешь посмотреть саму книгу, точнее то её превью, которое мы скачали. тем не менее, я продолжаюю поагать, что книги Худака и прочих основоположников лучше работы Хал-Ван Дама и сделаны в более педагогическом стиле
Книгу я смотрел. Можно конкретный момент? Я не видел там подобного изложения, поэтому и спрашиваю, что имеется в виду? Какой именно недостаток заметен?
L>>Ещё интересный момент. Ну это ко всем вопрос — считаете ли вы, что упражнения — это всегда хорошо, если нет, то в каких случаях нет.
BZ>человек учится только на практике. поэтому мой педагогический талант подсказывает мне, что каждое излагаемое теоретичсекое положение надо илдлюстрировать конкретными примерами, и добавлять задания для самостоятельного решения. кстати, одна из книг там сделана именно в таком ключе — [http://www.cs.ou.edu/cs1323h/textbook/twoDzn.zip]
Здравствуйте, Mirrorer, Вы писали:
L>> Ну это ко всем вопрос — считаете ли вы, что упражнения — это всегда хорошо, если нет, то в каких случаях нет.
M>Я считаю что для книг обучающих упражнения обязательно должны быть. Причем чем больше, тем лучше. И желательно с ответами. И с подробными объясненями хотя бы части ответов. А не просто "42".
Спасибо! А не сойдет ли вместо ответов использование объясняющих примеров перед тем, как даются упражнения?
Здравствуйте, BulatZiganshin, Вы писали:
BZ>ghc компилируется в натив, однако ленивые вычисления и ужаснейший кодогенератор не дают ему сколь-либо развернуться. а вот если взять ocaml (и даже clean с императивным кодом), то они близки к gcc. что касается байт-кода, то во-первых трудно противостоять таким монстрам, как gcc/icl, а уж тем более трудно это сделать, когда компиляция идёт через промежуточный этап, на котором теряется большая часть семантической информации. далее — языки типа c#/немерле/явы имеют более высокоуровневую модель, которая закономерно выливается в более медленный код. ну к примеру, данные всегда boxed. если же использовать unmanaged расширения этих языков, то никакого выигрыша в лёгкости программирования ты не получаешь
К сведению, выполенение кода на .NET обычно быстрее ОКамл-овского и обычно приближается к скорости лучших С++ компиляторов. Потеря семантической информации, имеют более высокоуровневую модель и т.п. — это набор фобий и заблуждений которые даже не смешно обсуждать. Если не согласен, то жду достовернно подтвержденных данных. Ну, а лечше просто почитай что-нибудь по данному впоросу. Тогда поймешь, что то что ты назваешь байткодом — это промежуточный код очень близкий промежуточному коду современных компиляторов вроде VC или GCC, точнее их бэкэнд. Информации в нем даже больше. Более того в будущем МС хочет перейти на единый бэкэнд — Феникс.
BZ>мне нечего добавить, кроме того, что "Вадлеров" (это вообще-то самый известный человек в FP) ты обидел незаслуженно
Более чем заслужено. Как писатели они нули без палочки. Мало знать предмет. Надо уметь изложить его доступно.
BZ>я (и не один я, конечно) пишу потихоньку статьи, объясняющие тонкости хаскела, которые я сам успел понять
Вот видишь? Если бы они не были плохоими писателями, то и тебе было бы не очем писать.
Если серьезно, то желаю тебе оказаться более талантливым писателем.
BZ>кстати, хорошо что напомнил. Visual Haskell (надстройка над VS) есть. она использует для компиляции ghc, т.е. интеграции во фреймворк нет. но по крайней мере intellisense работает. интерактивный отладчик в ghci уже появился, может через год-два он будет и в VH представлен
Я знаю, но сам не пробовал. Тут очень важно качество. Поделок то всегда много. А вот продуктов уровня интеграции для C# в VS2005 или IDEA я пока не видел.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Denis2005, Вы писали:
D>Теперь это сплошь и рядом, особенно после появления Nemerle
Тебе показалось. Как раз те кто выбираю Nemerle обычно не считают ФП панацеей. Просто шатающиеся рядом фанатики разных крайностей очень хотят представить все в извращенном виде.
D>(как ни крути, ФП его корневая парадигма).
Отнюдь. Как раз если программа более менее большая, то ее основа — это ООП. А фунциональные фичи применяются при реализации методов и обработке данных.
ЗЫ
Что до всплесков агресси, то они у гого хочешь будут когда столько доболомов шатаются по форуму вместо работы и флэймят по чем зря. Надо вообще, вводить квоты на прибывание на этом форуме .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Андрей Хропов, Вы писали:
VD>>А Хаскель — это очень медленно. АХ> Кто тебе это сказал?
Я пробовал.
Есть задачи на которых Хаскель показывает себя не плохо. Есть кое какие хитрости вроде тех что использованы в приведенных тобой тестах, но в среденм ленивость добходится довольно дорого. Плюс видимо не оптимальны компиляторы.
АХ>Haskell vs C++ АХ>Haskell vs Java
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>например, главная причина выпуска NET, на мой взгляд — стремление привязать разработчиков к одной платформе и отучить их писать переносимый софт, что уже было начало получаться с явой.
Мне кажется причина тут скорее в Сане. Он действовал (и продолжает действать) как сабака не сене. МС хотел развивать яву по своему, предложил это Сану, но те послали МС далеко и на долго. Дотнет был создан как объеденение трех проектов: добавления метаданных к С++, COM 2.0/COM+ и MS J++.
BZ> если бы существовала реальная конкуренция, то уже давно появились бы две-три фирмы с нормальными IDE под яву. а в нынешней ситуации их делать смысла нет
Для явы как раз есть 3 офигительных IDE: Эклипс, ИДЕА и какой-то там НетБинс (что ли).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
VD>>>Да что там они. Вот погляди: VD>>>http://www.haskell.org/haskellwiki/Frag VD>>>это Ку3 написанный на Хаскеле!
BZ>как не трудно догадаться, opengl билиотека, рендерящая всю эту хрень, написана на С. а хаскел выступает в качестве скриптового языка, выдающего ей задания
Какая разница? Движок написанный на С++ будет так же использовать эту сишную библиотеку. К тому же ОпенЖЛ-диблиотеки, по крайней мере под Виндовс, просто транслируют вызовы драйверам видио-адаптера, а те видо-адаптеру. Вычислени там почти нет.
Я этот пример привел к тому, что нет там каких-то сверх-задач требудющих все до единой строчки кода оптимизировать до невероятности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Я пробовал. VD>Есть задачи на которых Хаскель показывает себя не плохо. Есть кое какие хитрости вроде тех что использованы в приведенных тобой тестах, но в среденм ленивость добходится довольно дорого. Плюс видимо не оптимальны компиляторы.
в этих реализациях ленивость даже близко не использутся я ж говорю — они написаны в чисто императивном стиле
АХ>>Haskell vs C++ АХ>>Haskell vs Java
VD>
Здравствуйте, VladD2, Вы писали:
BZ>>например, главная причина выпуска NET, на мой взгляд — стремление привязать разработчиков к одной платформе и отучить их писать переносимый софт, что уже было начало получаться с явой.
VD>Мне кажется причина тут скорее в Сане. Он действовал (и продолжает действать) как сабака не сене. МС хотел развивать яву по своему, предложил это Сану, но те послали МС далеко и на долго.
Ну, естественно. Конкуренция понимаешь ли. Но для дружественных Сану фирм типа IBM никаких проблем нет.
VD> Дотнет был создан как объеденение трех проектов: добавления метаданных к С++, COM 2.0/COM+ и MS J++.
Мне кажется MS J++ здесь явно лишний. Вообще там Хейлсберга пригласили, который имел Pascal/Delphi background.
А как MS относится к J++ и продолжателю его дела J# может говорить хотя бы то что J# отдали писать в Индию .
А вот что следует ИМХО добавить — то, что катализатором развития .NET стала не только нарастающая конкуренция со стороны Java и недостатки COM, но и довольно неприятная для MS ситуация с безопасностью ее продуктов.
BZ>> если бы существовала реальная конкуренция, то уже давно появились бы две-три фирмы с нормальными IDE под яву. а в нынешней ситуации их делать смысла нет
VD>Для явы как раз есть 3 офигительных IDE: Эклипс, ИДЕА и какой-то там НетБинс (что ли).
VladD2 wrote: > Я этот пример привел к тому, что нет там каких-то сверх-задач требудющих > все до единой строчки кода оптимизировать до невероятности.
Q3 уже заметно устарел — там даже современной физики нет. А она весьма
прожорлива стала.
Еще в Q3 достаточно примитивный collision detector (они там просто по
BSP проходят), который тоже является весьма вычислительно-прожорливой
частью. А еще бывают зверства вроде совмещенных octree/BSP — это уже
заметно увеличивает вычислительную нагрузку.
VladD2 wrote: > Мне кажется причина тут скорее в Сане. Он действовал (и продолжает > действать) как сабака не сене. МС хотел развивать яву по своему, > предложил это Сану, но те послали МС далеко и на долго. Дотнет был > создан как объеденение трех проектов: добавления метаданных к С++, COM > 2.0/COM+ и MS J++.
Вот только у американского суда было другое мнение — во внутренних
документах MS были описаны планы по embrace&extend&extinguish Явы.
А процесс разработки Java, кстати, всегда был намного более открытым,
чем процесс разработки C#. Через JSR (Java Specification Request)
реально проводились достаточно сложные вещи.
Здравствуйте, Cyberax, Вы писали:
C>eao197 wrote: >> В общем, интересный момент в истории C>Расскажи им о Nemerle Заодно может и немерлистам от Александреску C>достанется.
Уже. Да и не только я. Там вообще народ при обсуждении метапрограммирования и Lisp, и Forth поминает.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Понятно, человеческий язык был не понят. Поэтому:
1) Я разговор с тобой прекращаю, бо бесполезно. Я не знаю зачем ты тут выливаешь потоки демагогии, но мне, по большому счету все равно.
2)
По прочтению топика сделал вывод, что подобное поведение твое не есть уникальный случай, но скорее правило. Посему предупреждаю — если подобные финты будут повторяться в том же объеме, я буду принимать меры с формулировкой "за перманентный оффтопик". Либо общайся по делу и по теме форума, либо лучше молчи.
... << RSDN@Home 1.2.0 alpha rev. 673 on Windows Vista 6.0.6000.0>>
Здравствуйте, lomeo, Вы писали:
L> А не сойдет ли вместо ответов использование объясняющих примеров перед тем, как даются упражнения?
По-моему — нет. По крайней мере у меня начинается ступор когда пусть даже после подробного оъяснения я начинаю решать задачу нового типа. А вот если бы таких задчек было штук 5. И в ответе к первой из них был бы дан какой-то хинт то эффективность обучения значитлеьно выше. Ну по крайней мере у меня.
D>Здравствуйте, VladD2, Вы писали:
VD>>... Надо вообще, вводить квоты на прибывание на этом форуме .
D>Судя по твоей активности на этом форуме, D>мне трудно представить, когда ты успеваешь спать.
он же прграммист, он давно написал программу, которая за него это делает. ну в смысле спит
Здравствуйте, BulatZiganshin, Вы писали:
D>>Судя по твоей активности на этом форуме, D>>мне трудно представить, когда ты успеваешь спать.
BZ>он же прграммист, он давно написал программу, которая за него это делает. ну в смысле спит
Здравствуйте, Cyberax, Вы писали:
C>VladD2 wrote: >> Я этот пример привел к тому, что нет там каких-то сверх-задач требудющих >> все до единой строчки кода оптимизировать до невероятности. C>Q3 уже заметно устарел — там даже современной физики нет. А она весьма C>прожорлива стала.
C>Еще в Q3 достаточно примитивный collision detector (они там просто по C>BSP проходят), который тоже является весьма вычислительно-прожорливой C>частью. А еще бывают зверства вроде совмещенных octree/BSP — это уже C>заметно увеличивает вычислительную нагрузку.
Ну, то есть ты тоже согласен, что никаких таких супер затрат при при выводе графики нет? Вот и славно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alexmoon, Вы писали:
A>Вам никогда не казалось то, что ваш вооруженный взгляд ошибается? Если ответите да, то я об этом не узнаю, а если нет, то ответ не верен, и врядли что либо изменит.
Казалось, но не в этом случае.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alexmoon, Вы писали:
VD>>ОК, тогда тебе не составит труда описать известные тебе языки с встроенными возможностями метапрограммирвоания объяснить почему ты считашь, что С++-ное метапрограммирвоание на шаблонах лучше, или хотя бы не хуже. Не составит?
A>Не составит конечно,
Много воды вырезано. Как я и прдпологал кроме множетсва пафосных но совершенно пустых фраз мы ничего и не услышали. Списка не будет просто потому, ты не знаком с такими языками.
Так вот тогда нечего лезть в споры с теми кто знаком, и пытаться их убедить в том, что их слова громкие или не соотвествуют действительности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alexmoon, Вы писали:
VD>>Представь себе идеомы бывают более и менее удачными. А бывает так, что что-то новое полностью поддерживает идиомы старых решений и предлагают кое-что нове. Или поддерживает идиому более чистым образом. Ну скажем, поддерживает метапрограммирование напрямую, без александревсовских ухищрений.
A>А есть такое?
Есть.
A>И при этом это что-то полностью сводит эффективность испольования чего то к нулю?
Нет. В абсолютных величинах, конечно нет. Как наличие гидравлического пресса не сводит на нет эффективность каменного топора. Но вот если смотреть на вещи относительно, то конечно эффективность каменного топора выглядит не лучшим образом. Так же и с метапрограммированием на шаблонах. Они просто не так удобны, эффективны, гибки. Но все еще ими можно пользоваться.
A>Не в ваших словах было аггресивное безальтернативное заявление? Мне не показалось это вопросительным, как запрос к обсуждению. Вы уже все решили, и при этом мнение других заведомая ошибка?
То что ты называешь "аггресивное безальтернативное заявление" на самом деле является констатацией факта. И ты можешь сам в этом убедиться просто попробовав и сопоставив результат.
VD>>А что же нелогичного в том, что нас что-то не устраивает? Может быть мы знаем как можно делать тоже самое, но лучше? A>Кто знает как делать лучше?
Мы.
A>Я так понимаю, готов список фамилий.
Да. В него войдут минимум четверь активных посетителей этого форума. Многие из них с С++-ным бэкэндом (Я, Вльфхаунд и ИТ по крайней мере точно).
A> И пожалуйста вдумайтесь глубже в мои слова глубже чем вам могло бы показаться. Это не утверждение обратного, а лишь вам знак того, что так же полностью объективны и восприимчивы к тому на что отвечают, а не ищите подвох в словах.
В думался. Не объективности со своей стороны не заметил.
A>Вы никогда не воспримите актуально суть происходящих вещей, отличных от вашего мнения. Я это тоже прозрачно понимаю не вооруженным взглядом.
Воспринимаю. И даже меняю свои убеждения. Но для этого нужны аргументы, ссылки и доказательства.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
CC>>>Не столько сложен, сколько сыроват. Работал с Havok 2 — тот гораздо стабильнее. Впрочем и в нем тогда с ragdoll была проблема, которую даже с их саппортом решить не удалось. E>>Хавок денег стоит, насколько мне известно. Нам их не дадут
AVK>Сильно
Здравствуйте, BulatZiganshin, Вы писали:
ПК>>Ты один работаешь или в команде?
BZ>это вообще хобби а к чему ты спрашиваешь?
Потому, что у меня сложилось впечатление, что о C/C++ ты судишь с позиции опыта коммерческой разработки софта. А о Хаскеле с позиции использования его для удовольствия. Не исключено, что после 3-4-х лет клепания программ на Хаскел под заказ, имея реальных заказчиков, обычную ротацию коллектива и другие факторы, твое мнение о качествах Хаскеля могло бы измениться в какую-то иную сторону.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Андрей,
LCR>>1. Человек ушёл с одного проекта на Java, который он писал где-то года 2. Парень, который пришёл на замену, провёл 10 месяцев, прежде чем написал первую строчку своего кода!!!
АХ> В смысле нового кода?
Да. Имеется конечно в виду не добавление "\n" в вызов log.debug(...), а добавление новой фичи.
LCR>>Меня просто ужас охватывал, когда он мне показывал список классов — он просто нажимает скроллинг и держал. А классы бежали и бежали. От имён уже начинало рябить в глазах, и наконец они сливались в одно непрерывное полотно, и лишь отпечатывался префикс C* или I*...
АХ>А сколько кода-то? Да и вообще чтобы один человек столько нагенерировал?
Да, кода много. Без учёта смежных библиотек (в которых тоже нужно разбираться) получается 1435 классов.
LCR>> По сравнению со сроком изучения системы, изучение языка это просто "о малое".
АХ>А что у вас за безумный проект такой? А документации, что, нет?
Андрей, к сожалению детали и цели я рассказать не могу. Из документации есть javadoc. Документации высокого уровня нет (и это считается нормальным ).
Порог вхождения действительно зашкаливает. Чтобы войти в проект, нужно проштудировать официальные доки — EJB tutorial, спеку и прочие. Позапускать примеры, чтобы хорошо разобраться с EJB, отличия 2.1 от 3.0. Потом посоздавать примеры, которые чуть-чуть цепляются за классы проекта, получить представление о внутренней механике. Потом ещё и ещё больше, пока наконец весь проект предстанет рисунком с маленькими белыми пятнами, а не наоборот. Возможно уникумы с феноменальной памятью справились бы лучше, но в данном случае считаю, что парень достоин уважения — он вывез-таки этот проект из стагнации и обучил ещё одного парня.
АХ>Я вот сейчас работаю с С++ библиотекой в которой порядка 800000 строк и 2200 классов, но в принципе с более-менее нормальной документацией (doxygen-сгенерированная + примеры), и навигацией по исходникам и как-то получается сразу .
Ахренеть, тоже проект-монстр. Если тебе удаётся сразу добавлять фичи и править баги, то ты просто молодец!
LCR>>Так что с позиции руководителя — 100% согласен, но с позиции практикующего программиста — только 20%
АХ>По-моему, наоборот, это программисту интереснее новые решения, эксперименты, креатив, а руководителю нужно чтобы программист просто работал как часы на стандартных технологиях и его легко можно было заменить если надо.
У тебя буквы легли неправильно. Именно это я и сказал: если я встану на позицию руководителя — то чем примитивнее и мэйнстримивее технология — тем лучше для меня, поэтому но пасаран ни Хаскелю, ни Немерлю, ни Окамлу и т.п. Но если я встану на позицию практикующего программиста — то многим новые языкам и технологиям можно и нужно уделять пристальное внимание, опять же не впадая в крайности.
C>>Еще в Q3 достаточно примитивный collision detector (они там просто по C>>BSP проходят), который тоже является весьма вычислительно-прожорливой C>>частью. А еще бывают зверства вроде совмещенных octree/BSP — это уже C>>заметно увеличивает вычислительную нагрузку.
VD>Ну, то есть ты тоже согласен, что никаких таких супер затрат при при выводе графики нет? Вот и славно.
При выводе нет, вот при подготовке к выводу конечно очень даже есть. (В Q3 подготовки в современном смысле,
почти и нет).
Здравствуйте, VladD2, Вы писали:
VD>Не. Это конечно не проблемы комитета. Ему просто по барабану. Это вообщене человек. У него нет единого мнения. Да и язык от тупого животного по имени комитет не помрет сразу. Он будет медленно деградировать или просто остановится в развитии.
. Вымрет в любом случае, но не из-за комитета. Это естественный процес . Но раньше чем появится полноценная альтернатива во всех областях где С++ рулит (рулил?). Этот процесс идет и вполне успешно, пока комитет пытается дать новые возможности, при этом не разрушить то, что есть. Одно другому не мешает. Только мне не понятно ваше усердие во вбивании гвоздей в крышку гроба. Анекдот напоминает.
Идет мужик(М) грустный с лопатой. Ему друг(Д) на всречу.
Д: — Привет, чего такой грустный?
М: — Да вот тещу похоронил.
Д: — Ясно. А чего лопата в крови?
М: — Упиралась.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
VladD2 wrote: > C>Еще в Q3 достаточно примитивный collision detector (они там просто по > C>BSP проходят), который тоже является весьма вычислительно-прожорливой > C>частью. А еще бывают зверства вроде совмещенных octree/BSP — это уже > C>заметно увеличивает вычислительную нагрузку. > Ну, то есть ты тоже согласен, что никаких таких супер затрат при при > выводе графики нет? Вот и славно.
При выводе непосредственно статической графики (то есть скармливание
треугольников карте) — да я разве когда-то против был?
А вот с подготовкой этой графики — очень даже есть. А то еще сейчас
пошла мода на полностью уничтожаемые миры — так там вообще динамический
пересчет BSP требуется, что весьма непросто.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, dr.Chaos, Вы писали:
DC>>ЗЫ Если уж придираться к орфографии и грамматике, давай придираться ко всем .
AVK>А я и не придирался вовсе, просто забавным показалось. А если тебе все же обидно за свои ляпы, так это не ко мне притензии.
Нет, не обидно. Просто вспомнилась пара постов Влада .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, BulatZiganshin, Вы писали:
ПК>>>Ты один работаешь или в команде?
BZ>>это вообще хобби а к чему ты спрашиваешь?
а это разве ты был? двуликий яенус
E>Потому, что у меня сложилось впечатление, что о C/C++ ты судишь с позиции опыта коммерческой разработки софта. А о Хаскеле с позиции использования его для удовольствия. Не исключено, что после 3-4-х лет клепания программ на Хаскел под заказ, имея реальных заказчиков, обычную ротацию коллектива и другие факторы, твое мнение о качествах Хаскеля могло бы измениться в какую-то иную сторону.
оба — для удовольствия. и что касается качества *языка* — я не думаю, что ротация коллектива как-то скажется на моём мнении. я ж тебе писал уже, что как и у каждого small языка, инфраструктура у хаскела несравнима с большой тройкой или даже delphi
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Хм, т.е. все улучшения которые дают Немерл и Окамл это уменьшение многословности? Мда уж что-то тогда индустрия на месте топчется получается, только шаги красивше и меньше выходят.
VD>Это ЗНАЧИТЕЛЬНОЕ увеличение уровня языка, при спопоставимой с С++ производительностью. VD>Давай простой эксперемент проведем.
Влад я понимаю, что является преимуществом Немерле и Окамл.
VD>К сожалени, человек практически не может оценить более мощьный язык. Об этом замечательно в свое время сказал Пол Грэхем
Ну да трудно описывать вкус котлет по киевски не разу их не попробовав.
VD>Вот попробуй сравнить классический ОО-код (на C#, правда, но на C++ он меньше не стал бы) на ООЯ с кодом на Немреле написанном в фукнциональном стиле: VD>Re[9]: Принцип подстановки Барбары Лисков
Влад ну ты сам же постоянно говоришь, что где-то ООП, где-то ФП, а где-то МП.
VD>Можно попробовать сравнить и на простых примерах. Покажи, например, как ты на С++ решил бы задачу преобразования массива целых (скажем std::vector<int>) в строку где каждое значение разделено запятой.
Не вижу смысла смотреть это на синтетических примерах. Мне все таки стало интересно, что может дать мне ФП в алгоритмах использующихся в движках. Уже начал Хаскель смотреть, потом и на Немерле гляну. Тогда можно будет сравнивать.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Здравствуйте, VladD2, Вы писали:
VD>>>Здравствуйте, dr.Chaos, Вы писали:
DC>>>>Переносимость на уровне исходников, это и есть основной приоритет комитета.
VD>>>К сожалению они добились полностью протевоположенного результата. DC>>Какого? Переносимости на уровне исходников нет? .
VD>Ага. Странно что ты считашь себя С++-программистом и не знал этого. Полной переносимости нет, так как компиляторы не реализуют стандарт, и так как стандарт изобилует кучей мест где возможно UB. Про то что такое UB объяснять надо?
DC>> Ты открыл мне глаза. Только как я компилюсь каждый деть с одним кодом под Win/AIX, может я что-то неправильно делаю??
VD>Ты используешь не весь С++, а его упрощенный сабсэт который переносим для выбранных тобой компиляторов. Причем ты находишь этот сабсэт по интуции тупо компилируя и тестирую код на обоих платформах. Так же ты избегаешь использования чужих библиотек, так как не хочешь разбираться в том, что они используют из "запрешенного С++".
И что? Я вообще на несовместимость СТЛ двух разных версий одного компилятора наткнулся. Она конечно была глубоко в кишках, но тем не менее весьма испортила настроение. Переносимость то есть, с оговорками и ограничениями, но есть.
DC>>Влад удобнее хотя бы потому, как это проверенный временем инструмент. Те что по-новее пока в стадии, если не разработки, то активного тестирования — не дальше.
VD>С тоже был проверен временем, а С++ молод и недоработан. Но почему-то ты на С сейчас не пишешь ведь.
Потому что С++ не молод уже . Вообще С++ дал возможность писать более сложные программы, продвинул новую парадигму. Кроме того до 90х годов его пользователями были весьма ограниченный круг людей которые его обкатывали, но это были фирмы которые могли себе позволить исследования и учебные заведения. Не думаю что производители игр(движков) относятся к одной из этих категорий.
VD>>>С++ марально устарел еще 5, а то и больше лет назад. Это здравый логический вывод. DC>>В чем его моральная старость?
VD>Во многом. Главный список фич: VD>1. Наличие моря UB.
Это не относиться к моральной старости у этого другие корни. VD>2. Отсуствие автоматического управления памятью.
Где-то плюс, где-то минус. VD>3. Не типобезопастность.
Ты про возможность грязных хаков, про наследие С или еще про что? VD>4. Наличие моря граблей в добавок к гланым гряблям из п. 3.
Хм, информативно VD>5. Плохая выразительность определяемая отсуствием в языке (вделенно так как библиотечная реализация перечисляемых фич сильно ущербна) удобных конструкций вроде функциональных объектов, интерфейсов (или классов типов Хаскеля если угодно), замыканий,
Очень сомневаюсь, что в С++ это нужно делать на уровне языка это еще больше его усложнит.
VD>модульности, метааднных, компонентности, сопоставления с образцом, полноценной системы метапрограммирования.
Итак только это можно считать его морально устаревшими чертами. Касаемо новых концепций для С++ МП и ФП их в язык точно вводить не надо, хотя бы потому что это будет смесь бульдога с носорогом, но, тем не менее, их можно использовать. Модульность и компонентность достичь только консенсусом производителей компиляторов, что ИМХО недостижимо по политическим причинам. А сопоставление с образцом ИМХО не такая уж и значимая концепция для С++, т.к. это фича декларативного подхода, но к моральной старость отнести трудно.
DC>>Каких именно слов? То, что это достаточно хороший инструме
VD>Например, вот этих: VD>
Кто кроме С++ дает такие возможности с обобщенным программированием при строгой типизации? Java, .Net?
VD>Чем тебе дженерики дотнета не обобщенное программирование при строгой типизации? И знаком ли ты с обобщенным программированием в Хаскеле и ОКамле, например?
DC>>Влад кто из производителей движков/ОС/драйверов переходит на Немерле/ОКамл/...
VD>Самые умные.
VD>>>Следующие должны писаться уже без С++, да и без скриптов. Технологии резко двинулись вперед и мы имеем все что имели и в скриптах, и в С++ (причем без их проблем) в одном флаконе.
DC>>Кому должны и где имеем?
VD>По логике должны. Но логика не всегда работает в человеческом мире.
Тогда по чьей логике?
DC>> Где 3Д библиотеки для Немерле/ОКамл/... которые удовлетворяют разработчиков движков?
VD>Они прекрасно исползуют имеющиеся бибилотеки. Для Немерле будет радным XNA, от МС и DirectX (хотя с выходом XNA смысла в последнем мало), для ОКамла лучше одойдет OpenGL, так как он довольно кросплатформынй. В прочем и для Немерла можно OpenGL исползовать. Инетроп у него отличный. Любые С-шные библотеки в виде dll/so он глотает без проблем.
Можно, но есть ли такие игры/движки?
DC>>Какие поименно? — причем в разрезе применения для ОС/драйверов/графических движков.
VD>Выразительность, типобезопасность, безграбельность, проверяемость (контрль времени компиляции за инвариантами и т.п.), ктаткость. В общем, почитай о том же Немерле или Скале хотя бы. А лучше попробуй. Уверяю тебя, что как только втянешся мнение твое резко начнет меняться. Я вообще-то тоже старый С++-ник. Просто меня перевербовали. Сначала через компонентные технологии, а потом и по астальным каналам.
Мда уж, ясно — это религия .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
DC>>>Какие поименно? — причем в разрезе применения для ОС/драйверов/графических движков.
VD>>Выразительность, типобезопасность, безграбельность, проверяемость (контрль времени компиляции за инвариантами и т.п.), ктаткость. В
DC>Мда уж, ясно — это религия .
прошу прощения, а что тогда для тебя — не религия? если программирующие на немерле возносятся прямо на небеса?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Короче, прекратим этот спор, т.к. я сомневаюсь что это прокатит в указанных мной случаях. Ты же не имея опыта работы с движками тоже не можешь утверждать. Но все таки я склоняюсь к мнению Cyberaxe здесь
.
VD>Я имею опыт написания быстрых программ на разных языках. В отличии от вас с Cyberax-ом. VD>Спор же действительно бессысленнен, так с верой спорить нельзя. А ваша вера в С++ носит чисто реалигиозный характер.
Здравствуйте, BulatZiganshin, Вы писали:
DC>>>>Какие поименно? — причем в разрезе применения для ОС/драйверов/графических движков.
VD>>>Выразительность, типобезопасность, безграбельность, проверяемость (контрль времени компиляции за инвариантами и т.п.), ктаткость. В
DC>>Мда уж, ясно — это религия .
BZ>прошу прощения, а что тогда для тебя — не религия? если программирующие на немерле возносятся прямо на небеса?
А ну да, ну да. Может все таки нирваны достигают? А то получается изучение Немерле убивает .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, BulatZiganshin, Вы писали:
E>>Потому, что у меня сложилось впечатление, что о C/C++ ты судишь с позиции опыта коммерческой разработки софта. А о Хаскеле с позиции использования его для удовольствия. Не исключено, что после 3-4-х лет клепания программ на Хаскел под заказ, имея реальных заказчиков, обычную ротацию коллектива и другие факторы, твое мнение о качествах Хаскеля могло бы измениться в какую-то иную сторону.
BZ>оба — для удовольствия. и что касается качества *языка* — я не думаю, что ротация коллектива как-то скажется на моём мнении. я ж тебе писал уже, что как и у каждого small языка, инфраструктура у хаскела несравнима с большой тройкой или даже delphi
Я говорил о совокупном впечатлении от качеств языка, а не об одном каком-то. И, по моему мнению, реальный пресс сроков, неожиданных требований заказчиков, думающих по другому коллег, возникающих в неподходящих момент глюков и пр., может очень сильно повлиять на впечатление от языка. Я же не зря привел пример реальной истории с коммерческим проектом -- не смотря на то, что кто-то считал Пролог хорошим языком, в данной конкретной ситуации со конкретными сроками, бюджетом и коллективом Пролог пришлось выбросить на свалку.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Я говорил о совокупном впечатлении от качеств языка, а не об одном каком-то. И, по моему мнению, реальный пресс сроков, неожиданных требований заказчиков, думающих по другому коллег, возникающих в неподходящих момент глюков и пр., может очень сильно повлиять на впечатление от языка. Я же не зря привел пример реальной истории с коммерческим проектом -- не смотря на то, что кто-то считал Пролог хорошим языком, в данной конкретной ситуации со конкретными сроками, бюджетом и коллективом Пролог пришлось выбросить на свалку.
ну с этой точки зрения ни о чём думать и не надо — любой язык за пределами большой тройки пролетает
Здравствуйте, Alexmoon, Вы писали:
A>Допускаю конечно , но и ты допусти пожалуйста то, что человеческий фактор у каждого проявляется по разному и от него не спасет ни одна фитча ни из любого языка. И бездумное использование даже смарт-поинтеров не спасет от этого, а лишь уменьшит вероятность. Я думаю нет смысла приводить, почему
Угу. "Познание бесконечности требует бесконечного времени, а потому работай-не работай — всё едино". Оно?
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Alexmoon, Вы писали:
A>>Допускаю конечно , но и ты допусти пожалуйста то, что человеческий фактор у каждого проявляется по разному и от него не спасет ни одна фитча ни из любого языка. И бездумное использование даже смарт-поинтеров не спасет от этого, а лишь уменьшит вероятность. Я думаю нет смысла приводить, почему S>Угу. "Познание бесконечности требует бесконечного времени, а потому работай-не работай — всё едино". Оно?
Не оно. Давай не будем раздражаться и продолжать оффтоп. Модератор прав. Чем меньше не аргументированной философии, тем чище язык.
Информации для размышления достаточно. Все с чем я согласен, я поставил оценку. Абсолютного мнения я не нашел. Лишь более или менее трезвые. Остальное я оставлю для собственного восприятия.
Здравствуйте, VladD2, Вы писали:
VD>ЗЫ
VD>Что до всплесков агресси, то они у гого хочешь будут когда столько доболомов шатаются по форуму вместо работы и флэймят по чем зря. Надо вообще, вводить квоты на прибывание на этом форуме .
Ага. Паспорт, прописка, место работы, разрешение от работодателя на посещение RSDN с часами дозволенного доступа.
С работодателей брать деньги за бан в рабочее время.
Hello, AndreiF!
You wrote on Wed, 07 Feb 2007 04:01:09 GMT:
PD>> А это один из критериев качества. Быстрее, меньше памяти PD>> требуется и т.д.
A> Качество — это когда программа делает свою работу правильно, не A> падает и не рушится. А скорость — это отдельный параметр, и к A> качеству никакого отношения не имеет.
Не так. Требования делятся на функциональные и нефункциональные. Программа считается качественной, когда она удовлетворяет и тем, и другим. Скорость (производительность) относится к нефункциональным требованиям. Они не всегда бывают сформулированы, но это не значит, что их нет.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, VladD2, Вы писали:
VD>>Где тот Чайф? CC>d:\mp3\Чайф\
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
D:\>dir /w
Volume in drive D is USB
Volume Serial Number is EC40-48BB
Directory of D:\
[CLIENT]
[Viezd]
Инструкция по установке вер.05.010.00_INTERNET_BANK2000.rtf
BANK2000.DDT
BANK7811.DDT
README!!.TXT
SIGN.KEY
SPR.DDF
VAL.DDF
WCLNT232.IST
SPRAV.EXE
[000]
9 File(s) 2 112 548 bytes
3 Dir(s) 32 252 928 bytes free
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>А вот с подготовкой этой графики — очень даже есть. А то еще сейчас C>пошла мода на полностью уничтожаемые миры — так там вообще динамический C>пересчет BSP требуется, что весьма непросто.
Ну, и какие тут у С++ приемущества?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>А вот с подготовкой этой графики — очень даже есть. А то еще сейчас > C>пошла мода на полностью уничтожаемые миры — так там вообще динамический > C>пересчет BSP требуется, что весьма непросто. > Ну, и какие тут у С++ приемущества?
Скорость, гибкая система управления памятью.
Я видел алгоритмы работы с BSP — это просто рай для С++. Умные указатели
со счетчиками ссылок и кастомные аллокаторы там просто рулят.
BZ>нет-нет, это С++ — сложный язык. а хочется поменять его на что-то более простое, чтобы не заучивать наизусть библию в 1000 страниц и не мучаться от того, что вы где-то инициализацию или блокировку забыли. кстати, насчёт инициализации:
Посмотри в "Исходниках" auto_value (как-то так, автор — Кодт, насколько я помню)
Здравствуйте, Cyberax, Вы писали:
C>Скорость, гибкая система управления памятью.
Скорость есть и в днугих местах. Что до гибкости, то это не гибкость — это низкоуровневость. Она конечно полезна для экономии, но вредна для надежности и эффективности программирования.
C>Я видел алгоритмы работы с BSP — это просто рай для С++. Умные указатели C>со счетчиками ссылок и кастомные аллокаторы там просто рулят.
Я тоже их видил и уверен, что ты ошибашся. Все твои подпорки только отвлекают от решения основной задачи.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
BZ>>например, главная причина выпуска NET, на мой взгляд — стремление привязать разработчиков к одной платформе и отучить их писать переносимый софт, что уже было начало получаться с явой.
VD>Мне кажется причина тут скорее в Сане. Он действовал (и продолжает действать) как сабака не сене. МС хотел развивать яву по своему, предложил это Сану, но те послали МС далеко и на долго. Дотнет был создан как объеденение трех проектов: добавления метаданных к С++, COM 2.0/COM+ и MS J++.
В смысле, "продолжает"? Java становится open source, вообще...
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, FR, Вы писали:
FR>Для PC это конечно так, но для тех же игровых приставок время жизни которых 5 — 7 лет, все гораздо печальнее, есть сейчас 512 Mb (притом общей и для видео и для приложении) памяти (или в другом случае 256 под приложения и 256 под видео) и больше в ближайшие годы точно не будет.
Фигдя. Сейчас в МС напишут первую игру для XNA и сразу найдут способ апгрэйда приставок. Причем после небольшой промывки мозгов покупателей реклмаой они с радостью будут сдавать баксы за планку памяти приговария "ах какое щастье что я не купил эту дорогущую бяку PS3, а вял Xbox у такой щедрой МС...".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Угу хорошая идея начать коммерческую разработку на языке который все еще в бете
Фигня. Скоро мы это устраним.
FR> (а судя по тому что недавно творилось в "Декларативном программировании" и как не смеялись некторые товарищи над багзилой другого языка в весьма глубокой).
На самом деле nikov — это наше секретное оружее. Если его на рилиз Ди направить, то он в нем столко ошибок найдет, что мало не покажется. Не даром МС уже его переманивает потихоничку.
Кстати, оно и дальше творится. Он находит по 1-3 ошибки в день. Примерно с этой же частотой они фиксятся. Лично у меня это вызвает годость за наших людей
FR>Притом каких-то больших преимуществ в скорости разработки по сравнению с C++ + хороший скрипт (питон, луа) вы не получите.
FR>Если рассматривать ситуацию Немерле vs (С++ + python) для тех же игр (правда я сейчас пишу только маленькие игры, но в больших тоже немного участвовал), то у Немерле по моему такие недостатки.
FR>1) Язык не зарелизиен, до промышленного уровня ему как минимум еще несколько лет. FR>2) Язык (именно язык) вполне хорош для написания внутренностей ядра и тому подобного в игре, но написанное на на нем проигрывает C++ (притом сильно если будет использоватся mono) в производительности и расходе памяти. Для многих жадных по памяти и процессору алгоритмов проигрыш может быть фатальным.
Интересно причем тут язык? Моно моной, бэта бэтой...
FR>3) Как язык для скриптов и вообще дизайнеров немерле слишком сложен, придется писать DSL, зная бардак с проектированием в игровых проектах 100% вы будете не один раз его переписывать, в общем лишняя работа обеспечена.
Не сложнее питона. При том логичнее во многом. Менее опытные могут использовать минимальный набор.
FR>4) DSL будет на макросах, и так как скорее всего часто будет менятся и поэтому точно не будет предкомпилированным, и учитывая что в игру могут грузится много сотен скриптов получите хороший тормоз при перекомпиляции и загрузке этого счастья (что то порядка минут вместо секунд для скрипта).
DSL у нас уже стал недостатком?! Класс!
FR>5) Для С/C++ для разработки игр море как готовых библиотек так и просто всякого рода примеров обучалок и тому подобного. Конечно некторые из них можно скомпилировать и вызывать через интероп, но многие нет, так как цена вызова может быть дороговатой.
Ну, про цену вызва все же не надо. Ты в этом явно не много понимаешь. Через интероп разве что арифметические действия слишком дорого вызвать.
FR>Так что добавится работа по переписыванию с С++.
Ага. Опять офигильный минус языка. Неясно только как же игры стали на С++ писать? Ведь раньше писали на ассемлерах.
FR>6) Платформа ограничена Windows и Xbox360. Есть mono для других платформ, но его производительности наверняка не хватит.
Windows и Xbox360 уже нехило. Рыног огромнеший. А учитывая, что PS3 оказалось явным сливом (600 баксов против 200 при более поганых играх — это приговор), то и думать не о чем.
В общем, ты как всегда сгущаещь краски. Язык тут вообще не причем. Если он нужен комьюнити, то для него можно и нэтивный компилятор сделать, и тучу библиотек, и спциальные ДСЛ-ли дря разных проблемных областей (игры лишь одна из них). А главное за него возмутся болшие конторы.
Вот наличие богатой лапы с огромным отделом маркетинга было бы точно джокером. Вот чего не хватает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR> FR>Надо его попросить.
Не, он человек наш — дотнетный. Вот только если в МС вманят.
FR>>>Притом каких-то больших преимуществ в скорости разработки по сравнению с C++ + хороший скрипт (питон, луа) вы не получите. WH>>Громно ржу.
FR>Зря.
А я кстати присоеденяюсь к ржанию. Действительно смешно. Темболее смешго читать продолжение, так как к языку в общем-то там претензий нет. Все или к незаконченности компилятора, или к рантайму (Моно), или к бардаку в конторах (который сам язык и будет в общем-то уменьшать).
FR>По устойчивости скорее близки. D тяжелей довести до ICE чем промышленные C++ компиляторы. Nemerle достаточно уcтойчив, но когда я с ним возился я и его (также как и D) доводил до ICE.
Ой. Готов побиться об заклад, что если как следует мотивировать nikov, то Ди будет летать как ласточка. Я когда вижу что он выдумывает в тестах, то тихо хринею. Я иной раз даже додуматься до такого не мог бы. Тут нужно какое-то дестуруктивное (в хорошем смысле этого слова) мышление. Он супер-тестер. Я не шучу.
FR>D на самом деле рановато присвоили 1.0, хотя с другой стороны сколько уже можно
Во-во.
FR>Проблемы может и временные, но работать то нужно здесь и сейчас.
Пока ты будешь работать (это 1-2 года) большинство из них уйдет. А интероп действительно решит твои проблемы. Плюс я тебе как дотнедчик со стажем могу подсказать 0некоторые хаки которые и в С++ то страшным сном будут казаться .
Если серьезно, то я вот думаю, не добавить ли по аналогии с asm инструкцию il. Ну, чтоб можно было хитрые выверты на MSIL тварить. Там ведь почти как в нормальном процессоре фичи есть. И типы платформно-зависимые, и инструкции хитрые. Толкьо вот опасное это оружие. Там можно таких дров наломать, что не то что верификация не пройдет, а летать будет хуже чем в С++.
FR>Угу. И платят плохо.
В этом и проблема. Плохая оплата отпугивает профи. Игроделы думаю что большое предложение работы обеспечивает выбор. Но ведь к ним ломятся только мальчики которые еще не наигрались в игры. Программистами им еще только предстоит стать. У них толко гонора много. Вот и выходит, что игры высокого качества делают только в Эипк, Вальше, АйДи и Близарде.
FR>Все равно даже предкомпилированная будет заметно медленее скриптов.
С чего бы это?
FR>Ну конечно мы пишем все сами и всегда наш код лучше чужого
На С++ это почти закон. Сам боялся брать чужие библиотеки.
FR>Мак очень даже имеет смысл, хотя для больших игр как не знаю, для маленьких очень приличный процент.
Мак теперь идет на PC-шном железе. Любой эмуляторов виндовс выше крыши. Производительность практически идеальная. В чем проблема то?
WH>>А на приставочном рынке Xbox360 не маленький сегмент.
FR>Но не доминирующий.
Еще как доминирующий. PS3 обостралась в дрызг. Xbox360 снимает сливки. И изменение ситуации вроде как не предвидится. В общем, Иили опять сфортило. Умеют же в его конторе риски просчитывать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
VD>>Мне кажется причина тут скорее в Сане. Он действовал (и продолжает действать) как сабака не сене. МС хотел развивать яву по своему, предложил это Сану, но те послали МС далеко и на долго. Дотнет был создан как объеденение трех проектов: добавления метаданных к С++, COM 2.0/COM+ и MS J++.
ПК>В смысле, "продолжает"? Java становится open source, вообще...
Гы-гы. А ты почитай что по этому поводу думает IBM . ОпенСорс ОпенСорсу рознь. Сан выпускает Яву под GPL 2. А IBM (точнее под его покровительством) ведет аналогичную разработку под BSD-лицензией. И шаг Сан полностью перкрывает возможность лития кода.
МС это как ты понимашь тоже не на руку. К тому же открывают они его только сейчас. Что позндновато. Хотя коды то были доступны и раньше. Только с ними вообще ничего сделать было нельзя.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
TBG>>Так пробелмы при отрисовке под win2k. VD>В последней версии TreeGrid я выбрасил оптимизации отрисовки и все должно быть нормально. Так что просто попробуй обновить Янус.
Здравствуйте, FR, Вы писали:
FR>4) DSL будет на макросах, и так как скорее всего часто будет менятся и поэтому точно не будет предкомпилированным, и учитывая что в игру могут грузится много сотен скриптов получите хороший тормоз при перекомпиляции и загрузке этого счастья (что то порядка минут вместо секунд для скрипта).
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Для PC это конечно так, но для тех же игровых приставок время жизни которых 5 — 7 лет, все гораздо печальнее, есть сейчас 512 Mb (притом общей и для видео и для приложении) памяти (или в другом случае 256 под приложения и 256 под видео) и больше в ближайшие годы точно не будет.
VD>Фигдя. Сейчас в МС напишут первую игру для XNA и сразу найдут способ апгрэйда приставок. Причем после небольшой промывки мозгов покупателей реклмаой они с радостью будут сдавать баксы за планку памяти приговария "ах какое щастье что я не купил эту дорогущую бяку PS3, а вял Xbox у такой щедрой МС...".
Угу сщас разбежались, хотя сони и нинтендо очень обрадуются
Не забывай приставки уже давно бытовой прибор. И даже такая вещь как варианты со смными жесткими дисками и без вызывают большое недовольство.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>> FR>>Надо его попросить.
VD>Не, он человек наш — дотнетный. Вот только если в МС вманят.
FR>>>>Притом каких-то больших преимуществ в скорости разработки по сравнению с C++ + хороший скрипт (питон, луа) вы не получите. WH>>>Громно ржу.
FR>>Зря.
VD>А я кстати присоеденяюсь к ржанию. Действительно смешно. Темболее смешго читать продолжение, так как к языку в общем-то там претензий нет. Все или к незаконченности компилятора, или к рантайму (Моно), или к бардаку в конторах (который сам язык и будет в общем-то уменьшать).
FR>>По устойчивости скорее близки. D тяжелей довести до ICE чем промышленные C++ компиляторы. Nemerle достаточно уcтойчив, но когда я с ним возился я и его (также как и D) доводил до ICE.
VD>Ой. Готов побиться об заклад, что если как следует мотивировать nikov, то Ди будет летать как ласточка. Я когда вижу что он выдумывает в тестах, то тихо хринею. Я иной раз даже додуматься до такого не мог бы. Тут нужно какое-то дестуруктивное (в хорошем смысле этого слова) мышление. Он супер-тестер. Я не шучу.
FR>>D на самом деле рановато присвоили 1.0, хотя с другой стороны сколько уже можно
VD>Во-во.
FR>>Проблемы может и временные, но работать то нужно здесь и сейчас.
VD>Пока ты будешь работать (это 1-2 года) большинство из них уйдет. А интероп действительно решит твои проблемы. Плюс я тебе как дотнедчик со стажем могу подсказать 0некоторые хаки которые и в С++ то страшным сном будут казаться .
Да ладно, в этом C++ точно не переплюнешь
VD>Если серьезно, то я вот думаю, не добавить ли по аналогии с asm инструкцию il. Ну, чтоб можно было хитрые выверты на MSIL тварить. Там ведь почти как в нормальном процессоре фичи есть. И типы платформно-зависимые, и инструкции хитрые. Толкьо вот опасное это оружие. Там можно таких дров наломать, что не то что верификация не пройдет, а летать будет хуже чем в С++.
А надо чтобы и летало и улетало лучше чем в C++
FR>>Угу. И платят плохо.
VD>В этом и проблема. Плохая оплата отпугивает профи. Игроделы думаю что большое предложение работы обеспечивает выбор. Но ведь к ним ломятся только мальчики которые еще не наигрались в игры. Программистами им еще только предстоит стать. У них толко гонора много. Вот и выходит, что игры высокого качества делают только в Эипк, Вальше, АйДи и Близарде.
Согласен.
В некторых местах ситуация меняется но медленно и обычно только для ведущих специалистов. Но объявления о вакансиях до сих пор месяцами на многих сайтах висят не закрытые.
FR>>Все равно даже предкомпилированная будет заметно медленее скриптов.
VD>С чего бы это?
С того что видно своими собственными глазами.
FR>>Ну конечно мы пишем все сами и всегда наш код лучше чужого
VD>На С++ это почти закон. Сам боялся брать чужие библиотеки.
Не надо преувиличивать.
FR>>Мак очень даже имеет смысл, хотя для больших игр как не знаю, для маленьких очень приличный процент.
VD>Мак теперь идет на PC-шном железе. Любой эмуляторов виндовс выше крыши. Производительность практически идеальная. В чем проблема то?
И что? Это никак ни отменяет относительный дифицит игр под MAC OS.
WH>>>А на приставочном рынке Xbox360 не маленький сегмент.
FR>>Но не доминирующий.
VD>Еще как доминирующий. PS3 обостралась в дрызг. Xbox360 снимает сливки. И изменение ситуации вроде как не предвидится. В общем, Иили опять сфортило. Умеют же в его конторе риски просчитывать.
Скорее сфортило нинтендо. А что будет в конкуренции сони — мс увидим через пару лет.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Угу хорошая идея начать коммерческую разработку на языке который все еще в бете
VD>Фигня. Скоро мы это устраним.
Давайте
FR>> (а судя по тому что недавно творилось в "Декларативном программировании" и как не смеялись некторые товарищи над багзилой другого языка в весьма глубокой).
VD>На самом деле nikov — это наше секретное оружее. Если его на рилиз Ди направить, то он в нем столко ошибок найдет, что мало не покажется. Не даром МС уже его переманивает потихоничку.
VD>Кстати, оно и дальше творится. Он находит по 1-3 ошибки в день. Примерно с этой же частотой они фиксятся. Лично у меня это вызвает годость за наших людей
FR>>Притом каких-то больших преимуществ в скорости разработки по сравнению с C++ + хороший скрипт (питон, луа) вы не получите.
VD>
Я конечно понимаю что новый хороший язык который дает фичи о которых вы явно или даже подсознательно мечтали сильно действует на психику, да еще если сюда добавить одновременный хотя бы частичный переход матерых императивщиков на функциональщину то крыша может и совсем слететь .
Но если трезво сесть и подумать, просчитать при этом процент чистого кодирования, протитпирования, подгонки (этап который в других типах приложенией обычно отсутствует) в разработке игр, то так оно и будет. Если еще учесть первоначальный переход на новый инструмент то скорость разработки первой игры будет гарантировано ниже. А учитывая что разработка игр очень рискованный бизнес то почти гарантированно все завалится.
Реально начинать разработку на немерле(да и на другом не мейнстримном языке тоже) можно только если проект начинается с нуля и при этом ты можешь набрать ядро таких же фанатиков помешанных на языке. В реальной жизни это как выигрыш в лоторею. И не надо песню про постепенное обущение или использование немерле как улучшенного шарпа. При таких зарплатах никто ни будет учить, да и улучшеный шарп скорее хуже чем смесь C++ и скрипта.
FR>>Если рассматривать ситуацию Немерле vs (С++ + python) для тех же игр (правда я сейчас пишу только маленькие игры, но в больших тоже немного участвовал), то у Немерле по моему такие недостатки.
FR>>1) Язык не зарелизиен, до промышленного уровня ему как минимум еще несколько лет. FR>>2) Язык (именно язык) вполне хорош для написания внутренностей ядра и тому подобного в игре, но написанное на на нем проигрывает C++ (притом сильно если будет использоватся mono) в производительности и расходе памяти. Для многих жадных по памяти и процессору алгоритмов проигрыш может быть фатальным.
VD>Интересно причем тут язык? Моно моной, бэта бэтой...
Тем что его в такой жадной до производительности отрасли как разработка игр сейчас просто невозможно использовать если нужна кросплатформенность.
FR>>3) Как язык для скриптов и вообще дизайнеров немерле слишком сложен, придется писать DSL, зная бардак с проектированием в игровых проектах 100% вы будете не один раз его переписывать, в общем лишняя работа обеспечена.
VD>Не сложнее питона. При том логичнее во многом. Менее опытные могут использовать минимальный набор.
Мне кажется сложнее. Хотя это не нам с тобой судить, у нас глаза замыленные.
FR>>4) DSL будет на макросах, и так как скорее всего часто будет менятся и поэтому точно не будет предкомпилированным, и учитывая что в игру могут грузится много сотен скриптов получите хороший тормоз при перекомпиляции и загрузке этого счастья (что то порядка минут вместо секунд для скрипта).
VD>DSL у нас уже стал недостатком?! Класс!
У нас стало недостатком разработка качественного DSL людьми которые этим никогда раньше не занимались. Цена ошибки будет очень высока.
FR>>5) Для С/C++ для разработки игр море как готовых библиотек так и просто всякого рода примеров обучалок и тому подобного. Конечно некторые из них можно скомпилировать и вызывать через интероп, но многие нет, так как цена вызова может быть дороговатой.
VD>Ну, про цену вызва все же не надо. Ты в этом явно не много понимаешь. Через интероп разве что арифметические действия слишком дорого вызвать.
А несколько десятков Mb гонять, да еще с обработчиками обратного вызова?
FR>>Так что добавится работа по переписыванию с С++.
VD>Ага. Опять офигильный минус языка. Неясно только как же игры стали на С++ писать? Ведь раньше писали на ассемлерах.
Ну конечно писали на ассемблерах и вдруг все в один день стали писать на C++.
FR>>6) Платформа ограничена Windows и Xbox360. Есть mono для других платформ, но его производительности наверняка не хватит.
VD>Windows и Xbox360 уже нехило. Рыног огромнеший. А учитывая, что PS3 оказалось явным сливом (600 баксов против 200 при более поганых играх — это приговор), то и думать не о чем.
Есть еще Wii, да и кто победит в итоге Сони или MS пока под большим вопросом.
VD>В общем, ты как всегда сгущаещь краски. Язык тут вообще не причем. Если он нужен комьюнити, то для него можно и нэтивный компилятор сделать, и тучу библиотек, и спциальные ДСЛ-ли дря разных проблемных областей (игры лишь одна из них). А главное за него возмутся болшие конторы.
Нет это ты бежишь впереди паравоза. Вот когда все это будет, тогда язык и начнут реально использовать.
Я вообще не сгущаю краски, скорее наоборот тоже оптимистичнее на это смотрю чем средний разработчик или руководитель. Реальность в той же игровой индустрии еще хуже, люди на си пишут и боятся переходить на C++ а от скриптов вообще круглые глаза делают.
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, FR, Вы писали:
FR>>4) DSL будет на макросах, и так как скорее всего часто будет менятся и поэтому точно не будет предкомпилированным, и учитывая что в игру могут грузится много сотен скриптов получите хороший тормоз при перекомпиляции и загрузке этого счастья (что то порядка минут вместо секунд для скрипта).
K>А кто мешает организовать кэш?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, CreatorCray, Вы писали:
CC>>Здравствуйте, VladD2, Вы писали:
VD>>>Где тот Чайф? CC>>d:\mp3\Чайф\
VD>
VD>Microsoft Windows [Version 6.0.5744]
VD>Copyright (c) 2006 Microsoft Corporation. All rights reserved.
VD>D:\>dir /w
VD> Volume in drive D is USB
VD> Volume Serial Number is EC40-48BB
VD> Directory of D:\
VD>[CLIENT]
.......
VD>BANK2000.DDT
VD>BANK7811.DDT
.......
VD>
Здравствуйте, lomeo, Вы писали:
A>>Не сказал бы что хорошая книга, доступность-доступностью, но стиль изложения в виде "это просто надо запомнить" наводит тоску. А последние главы вообще смазаны и "предполагается очевидность". L>О, очень интересно. А можно приблизительный пример — "это надо запомнить" изложения и как бы это хотелось видеть? Это не для флейма, это для меня.
Ммм, я не имел ввиду, что прям вот так и написано, что "некое понятие" нельзя понять и надо запомнить. Я о том, что достаточно сложным понятиям уделено минимум внимания, и всё объяснение заключается в нескольких предложениях, которые мало что проясняют для незнающего человека. В этой книге так рассматриваются практически все значимые для ФП понятия ака лямбды, карринг, функции высшего порядка. Даже генераторы списков, вроде бы и расписаны и с многими примерами, а всё равно кажутся "птичей грамотой". Хотя вот рекурсия (как обычно ) объяснена вполне грамотно и достаточно полно.
А где-то примерно с главы о "функциях высшего порядка" начинается вообще полная чехарда.
A>>В принципе, если читать как введение в язык до чтения всяческих Tutorials — то вполне пойдёт, а если заставить себя выполнять упражнения, то наверное ещё и эффект понимания будет (кстати стиль чем-то SICP напоминает). L>Ещё интересный момент. Ну это ко всем вопрос — считаете ли вы, что упражнения — это всегда хорошо, если нет, то в каких случаях нет.
Думаю, что это зависит от человека и его способа восприятия. Кому-то легче воспринимать примерами, а кому-то изначальными посылками идеи и целями, которые она позволяет достичь. А закреплять всё равно надо практикой, до которой упражнениям очень далеко
Спасибо!
A>Ммм, я не имел ввиду, что прям вот так и написано, что "некое понятие" нельзя понять и надо запомнить. Я о том, что достаточно сложным понятиям уделено минимум внимания, и всё объяснение заключается в нескольких предложениях, которые мало что проясняют для незнающего человека. В этой книге так рассматриваются практически все значимые для ФП понятия ака лямбды, карринг, функции высшего порядка.
Супер, за список спасибо отдельное! Если есть что в него добавить — жду с нетерпением.
A>Даже генераторы списков, вроде бы и расписаны и с многими примерами, а всё равно кажутся "птичей грамотой". Хотя вот рекурсия (как обычно ) объяснена вполне грамотно и достаточно полно.
Да, мне тоже понравилась эта глава.
A>А где-то примерно с главы о "функциях высшего порядка" начинается вообще полная чехарда.
Тут, если можно, тоже чуть чуть конкретики. В чём именно чехарда, как на твой (ваш?) взгляд надо было подать этот материал. В общем в стил — что ожидает читатель и что он получил, если можно.
A>Думаю, что это зависит от человека и его способа восприятия. Кому-то легче воспринимать примерами, а кому-то изначальными посылками идеи и целями, которые она позволяет достичь. А закреплять всё равно надо практикой, до которой упражнениям очень далеко
Упражнения необходимы — так (я исхожу из слова "надо")? Или всё же желательны?
Здравствуйте, FR, Вы писали:
FR>Угу сщас разбежались, хотя сони и нинтендо очень обрадуются
Нинтендо вылетело из драки за "большие" приставки еще в прошлый раз. Сони похоже в этот. Ты хоть прессу то читаешь?
FR>Не забывай приставки уже давно бытовой прибор. И даже такая вещь как варианты со смными жесткими дисками и без вызывают большое недовольство.
Бытовой прибор за 600 баксов отсуствующий в продаже несколько хуже бытового прибора за 200 (который не только присуствует, но и игры уже хитовые имеет).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Кэш сильно поможет? FR>Особенно если меняется DSL.
Не будет вообще проблем со скоростью в данном вопросе. Вооще не будет. В Немерле DSL — это такой же код как код компилятора. Если он изменился, то надо перекомпилировать сборку с ним. Далее он убдет работать со скоростью машинных инструкций.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Для описания столь сложных моделей использовался язык декларативного описания моделей, специализированный DSL, на написание и доводку которого ушло пару лет. Вот в таком тандеме плюсы рулили.
Очень даже верю.
В одном из моих последних проектов у меня С++ просто работал в связке с перлом, который генерил С++-код из разных веселых файлов.
IT>Тем не менее сегодня существуют языки, которые способны решать не менее эффективно весь комплекс проблем. При этом два года на написание компилятора и движка моделей точно не понадобится.
Ну и хорошо
Я что, где-то разве утверждал, что хаскель, немерле, лисп и прочая — это отстойные языки, которым лучше бы не появляться на свет?
Конечно, хорошо, когда язык метапрограммирование поддерживает напрямую, как С++ напрямую поддерживает ООП в сравнении с С.
Никто с этим не спорит — это очевидно.
Здравствуйте, Mirrorer, Вы писали:
M>Здравствуйте, lomeo, Вы писали:
L>> Ну это ко всем вопрос — считаете ли вы, что упражнения — это всегда хорошо, если нет, то в каких случаях нет.
M>Я считаю что для книг обучающих упражнения обязательно должны быть. Причем чем больше, тем лучше. И желательно с ответами. И с подробными объясненями хотя бы части ответов. А не просто "42".
Вот, кстати, с "Математикой" шла прекрасная книга, все разжевывалось уж не знаю до какой степени.
Не знаю, правда, есть ли она в электронном виде. Вроде, я ее видел как часть ее хелпа, но руку не дам на отсечение.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Угу сщас разбежались, хотя сони и нинтендо очень обрадуются
VD>Нинтендо вылетело из драки за "большие" приставки еще в прошлый раз. Сони похоже в этот. Ты хоть прессу то читаешь?
Я да, а ты похоже нет, хотя ты конечно умеешь многое читать и не видеть.
http://gadgets.compulenta.ru/303941/?r1=rss&r2=remote
FR>>Не забывай приставки уже давно бытовой прибор. И даже такая вещь как варианты со смными жесткими дисками и без вызывают большое недовольство.
VD>Бытовой прибор за 600 баксов отсуствующий в продаже несколько хуже бытового прибора за 200 (который не только присуствует, но и игры уже хитовые имеет).
Пока это ничего ни значит, просто споткнулся на старте. Время жизни 5 — 7 лет посмотрим что дальше будет и не окажутся ли и сони и мс с носом.
J>В одном из моих последних проектов у меня С++ просто работал в связке с перлом, который генерил С++-код из разных веселых файлов.
А почему именно перл, если не секрет? Я бы от этого монстра бежал бы как от огня...
Здравствуйте, Left2, Вы писали:
J>>В одном из моих последних проектов у меня С++ просто работал в связке с перлом, который генерил С++-код из разных веселых файлов. L>А почему именно перл, если не секрет? Я бы от этого монстра бежал бы как от огня...
Не знаю
Нравится он мне
И я его знаю, еще когда 4-я версия была
Меня хлебом не корми — дай чего-нть отрегэкспить, недаром у меня любимый редактор — NEdit.
Ну и потом код был наполнен всякими операциями типа map (или как оно там называется) и тому подобным.
И "write-only" код у меня тоже никогда не было склонности писать, разве что на спор
Никаких особых проблем я с ним не испытывал, как и с С++, в общем-то. Наверное, я действительно извращенец
P.S. Хотя что-то там мне в нем не нравилось, когда наворотишь здоровенную структуру с хэшами и списками и ссылками внутри — какие-то там были у меня проблемы, но я уже плохо помню, если честно.
J>>>В одном из моих последних проектов у меня С++ просто работал в связке с перлом, который генерил С++-код из разных веселых файлов. L>>А почему именно перл, если не секрет? Я бы от этого монстра бежал бы как от огня...
J>Не знаю J>Нравится он мне J>И я его знаю, еще когда 4-я версия была J>Меня хлебом не корми — дай чего-нть отрегэкспить, недаром у меня любимый редактор — NEdit. J>Ну и потом код был наполнен всякими операциями типа map (или как оно там называется) и тому подобным. J>И "write-only" код у меня тоже никогда не было склонности писать, разве что на спор
Ну, регэкспы-то сейчас практически в любом скриптовом языке есть. В том же JavaScript, или в Python. Просто я книгу по перлу смог дочитать только процентов на 15 — уж очень жуткая мешанина там в синтаксисе, просто ужас. Ну и map — не знаю как Python, а в JS это делается ещё проще чем в Perl.
Здравствуйте, Left2, Вы писали:
J>>>>В одном из моих последних проектов у меня С++ просто работал в связке с перлом, который генерил С++-код из разных веселых файлов. L>>>А почему именно перл, если не секрет? Я бы от этого монстра бежал бы как от огня...
J>>Не знаю J>>Нравится он мне J>>И я его знаю, еще когда 4-я версия была J>>Меня хлебом не корми — дай чего-нть отрегэкспить, недаром у меня любимый редактор — NEdit. J>>Ну и потом код был наполнен всякими операциями типа map (или как оно там называется) и тому подобным. J>>И "write-only" код у меня тоже никогда не было склонности писать, разве что на спор
L>Ну, регэкспы-то сейчас практически в любом скриптовом языке есть. В том же JavaScript, или в Python. Просто я книгу по перлу смог дочитать только процентов на 15 — уж очень жуткая мешанина там в синтаксисе, просто ужас. Ну и map — не знаю как Python, а в JS это делается ещё проще чем в Perl.
Верю.
Но когда Perl победоносно шагал по планете со своими регэкспами, JS толкьо в проекте был, а когда появился ,максимум, на что он годился — немножко работать в контексте браузера. С Python-ом та же самая история. В это же время, кстати, когда эти скрипты только вылезали из пеленок, появился 5-й перл.
Сейчас, конечно, у них уже чего только нет, и рефлексия, и ФП, и duck typing...
Но мне для процессинга текста всегда перла хватало за глаза.
И паттерн-матчинга в буквальном его исполнении (s///) мне тоже хватало
P.S. Вот всюду вам монстры чудятся Что Перл, что С++
А мы их приручили давно
Это ж как живое существо, со своими закидонами. Если долго с ним живешь — перестаешь закидоны замечать, с одной стороны — из-за привычки, с другой — потому что уже давно научился либо не попадать на эти закидоны, либо нейтрализовывать последствия, это уже все в подкорке.
Теперь понятно
Просто в начинающийся прямо сейчас новый проект перл я бы не стал впихивать под страхом смертной казни Поскольку не так уж много народу его знает, а тем кто его не знает учить его и плеваться прийдётся долго. Тот же JavaScript я берусь обьяснить человеку за один час практически в полном обьёме, после этого для него практически не останется граблей в синтаксисе языка. А вот perl — тут нужно кучу шишек набить прежде чем с ним освоишься + запомнить гору информации (всякие там $_, $^ и т.п.). Но для человека имеющего большой опыт разработки в каком-либо скриптовом языке чаша весов при выборе скриптовых языков неминуемо склонится к уже известному, тут я согласен.
Здравствуйте, VladD2, Вы писали:
CU>>Хм, а на этом "убийце скриптов" можно не перезапускать основную программу после изменения отдельного маленького компонента, а просто указать, что если "скриптик" Х изменился после последней его загрузки — загрузить его заново?
VD>Можно.
Здравствуйте, cl-user, Вы писали:
CU>>>Хм, а на этом "убийце скриптов" можно не перезапускать основную программу после изменения отдельного маленького компонента, а просто указать, что если "скриптик" Х изменился после последней его загрузки — загрузить его заново?
VD>>Можно.
CU>Что читать?
Тут нет ни слова про Хбокс. Все сравнения с обосравшейся PS3.
Меж тем Нитендовская приставка просто ниже классом. У нее и графика не та и возможностей меньше.
Для нее игры скорее всего будут специфические.
В общем, рынка Хбокс и Виндовс хватит за глаза. Лучше игру сделать более качествнную.
FR>Пока это ничего ни значит, просто споткнулся на старте. Время жизни 5 — 7 лет посмотрим что дальше будет и не окажутся ли и сони и мс с носом.
Значит, еще как значит. Для Иксбокса уже более 100 игр сделано и в среднем они выглядят лучше чем PS3-шные (и это при том что теоритически PS3 должна быть сильно круче).
Уже есть сообщения, что PS4 вовсе не убдет. Слухи конечно, но на ровном месте таких слухов не бвывает.
Ну, а рынок PS3 в значительной мере будет отходить именно Иксбоксу как к сравнимому по возможностям девайсу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
CC>Ну, закинул бы все равно — просто для сравнения эффективности алгоритмов. Все равно для практического применения из их списка архиваторов пригодно процентов 20-30%. Остальные такие же спортивные эксперименты...
Ага. Их победитель — WinRK — на 43-ей минуте показвал 0% прогресса (на архивации БД РСДН-а — 5.5 ГБ), а с утра вообще не было видно что он даже начинал архивировать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>однако тем не менее сделать архиватор, который будет жать лучше, чем 7-zip, труда не составляет. достаточно взять lzma (доступный в исходниках), прикрутить к нему ppmd для текстовых файлов, добавить несколько препроцессоров — и комплексный обед готов. в моей программе испольщзуется штук 8 алгоритмов сджатия, причём я сам написал только два из них, довольно мелких. поэтому нет ничего удивительного в том, что программа сжимает лучше и быстрее оригинала, на котором она базируется. специалисту для того, чтобы понять, как она будет сжимать, достаточно прочесть список использованных алгоритмов — ну знаете, как в этом анекдоте "- анекдот 885! — все смеются, один не смеётся"
BZ>над вопросами практического применения я сейсчас потихоньку и работаю. надёжность, фичи, расширяемость формата архива
А не хочешь статейку популярную о внутренностях архиваторов написать для РСДН-а?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, CreatorCray, Вы писали:
CC>>Ну, закинул бы все равно — просто для сравнения эффективности алгоритмов. Все равно для практического применения из их списка архиваторов пригодно процентов 20-30%. Остальные такие же спортивные эксперименты...
VD>Ага. Их победитель — WinRK — на 43-ей минуте показвал 0% прогресса (на архивации БД РСДН-а — 5.5 ГБ), а с утра вообще не было видно что он даже начинал архивировать.
"на вашем месте я бы обратился к специалисту"
Влад, самый мозный алгоритм WinRK (а ты вряд ли воспольщзовался каким-либо иным ) имеет скорость порядка 1кб/с, причём при распаковке тоже
у него есть редимы поскромнее, но на моих тестах они дико глючили. на несколькихх файлах они наверно отработают нормально. вообще, смотри 7zip. uharc обрабатывает до 2 гиг только
кстати, прфессиональный интерес — у вас текстовые данные перемежаются в базе с бинарной служеьной информацией или они идут большими кусками — отдельно текст, отдельно всякие там индексы?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>однако тем не менее сделать архиватор, который будет жать лучше, чем 7-zip, труда не составляет. достаточно взять lzma (доступный в исходниках), прикрутить к нему ppmd для текстовых файлов, добавить несколько препроцессоров — и комплексный обед готов. в моей программе испольщзуется штук 8 алгоритмов сджатия, причём я сам написал только два из них, довольно мелких. поэтому нет ничего удивительного в том, что программа сжимает лучше и быстрее оригинала, на котором она базируется. специалисту для того, чтобы понять, как она будет сжимать, достаточно прочесть список использованных алгоритмов — ну знаете, как в этом анекдоте "- анекдот 885! — все смеются, один не смеётся"
BZ>>над вопросами практического применения я сейсчас потихоньку и работаю. надёжность, фичи, расширяемость формата архива
VD>А не хочешь статейку популярную о внутренностях архиваторов написать для РСДН-а?
хотеть конечно не хочу а что тебя, как типичного читателя, собcтвенно интересует? что касается сжатия — то право слово, все 8 библиотек, что я использовал, находятся в открытом доступе
Здравствуйте, BulatZiganshin, Вы писали:
BZ>у него есть редимы поскромнее, но на моих тестах они дико глючили. на несколькихх файлах они наверно отработают нормально. вообще, смотри 7zip. uharc обрабатывает до 2 гиг только
Так там 7zip и используется.
Причем сначала моим diff'ом выделяется разница между двуми бэкапами, а потом эта разница уже 7zip'ится.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>у него есть редимы поскромнее, но на моих тестах они дико глючили. на несколькихх файлах они наверно отработают нормально. вообще, смотри 7zip. uharc обрабатывает до 2 гиг только WH>Так там 7zip и используется. WH>Причем сначала моим diff'ом выделяется разница между двуми бэкапами, а потом эта разница уже 7zip'ится.
баста, карапузики это лучшее на данный момент сжатие
Здравствуйте, BulatZiganshin, Вы писали:
BZ>хотеть конечно не хочу а что тебя, как типичного читателя, собcтвенно интересует? что касается сжатия — то право слово, все 8 библиотек, что я использовал, находятся в открытом доступе
Интересует популярное изложение, что, как, и почему устроено. В чем суть алгоритмов? Какие алгоритмы лучше для каких данных? В общем, популярно о предметной области. Вряд ил эти знания окажутся полезны большинству народа, но будет интересно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Самое смешное в этом то, что ни Александреску, ни Брайт пока сами не знают, что же это будет за макро система такая. Об этом Брайт где-то прямым текстом заявил (я читаю digitalmars.D через Opera, поэтому не могу дать точную ссылку на новость через Web-интерфейс).
Главно ему Немерле не показывать.
E>Более того, сейчас народ пытается разобраться, что с новыми mixin-ами реально можно делать и как бы сделать так, чтобы не было отдельного compile time D
А, у них ручаня специализация шаблонов и вычисления в них поддерживаются?
E> (для обработки текстовых миксинов) и отдельного run-time D. К Александреску пристали, чтобы он хоть какие-то реальные примеры привел из того, что он хочет иметь. Он смог представить только пример с black и white box имплементацией интерфейсов для тестовых целей. За что на него даже наехали, мол люди пытаются на D реальные задачи решать, а вы здесь какими-то теоритическими изысканиями занимаетесь.
Люди реально рясут, этот теоретик подумать предлагает...
E>Причем люди стали приводить весьма нетривиальные примеры DSL-ей, для обработки которых возможностей шаблонов и static if, на мой взгляд, явно не хватит. Что интересно, Брайт пока молчит. Может быть задем каким-нибудь оригинальным решением разродится -- вроде плагинов к компилятору, которые будут заниматься compile-time обработкой DSL.
Ага. Главное чтобы в императивном режиме все было. Ну, чтобы каждый плагин с пол компилятора размером.
E>В общем, интересный момент в истории
Ага. Люди дошли до конца и поняли, что пришли в тупик.
Теперь самое время взят и почитать труды тех кто давно и плодотворно работает с маросами.
В принципе решение на поверхности лежит — квазицитирование и паттерн-матчинг. Но боюсь до этого они так и не дойдут и будет как ты говоришь — два Ди.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
C>>Расскажи им о Nemerle Заодно может и немерлистам от Александреску C>>достанется.
E>Уже. Да и не только я. Там вообще народ при обсуждении метапрограммирования и Lisp, и Forth поминает.
Дал бы ссыклу. Интересно почитать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>>Уже. Да и не только я. Там вообще народ при обсуждении метапрограммирования и Lisp, и Forth поминает.
VD>Дал бы ссыклу. Интересно почитать.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Я да, а ты похоже нет, хотя ты конечно умеешь многое читать и не видеть.
FR>>http://gadgets.compulenta.ru/303941/?r1=rss&r2=remote
VD>Тут нет ни слова про Хбокс. Все сравнения с обосравшейся PS3.
VD>Меж тем Нитендовская приставка просто ниже классом. У нее и графика не та и возможностей меньше. VD>Для нее игры скорее всего будут специфические.
То что она ниже классом ничего ни значит, зато пиар у них выше чем у ms и сони вместе взятых. Та же карманная приставка от нинтендо тоже ниже классом чем у сони но продается
лучше. Так что это как раз не так важно.
VD>В общем, рынка Хбокс и Виндовс хватит за глаза. Лучше игру сделать более качествнную.
Мда уж. Такое чувство, что разговор о языках сводится к не лучшим их представителям (C, C++, Java, C#) С таким скудным кругозором едва ли до чего полезного можно будет договориться.
Весь топик пока не прочитал, D только видел, где-то в начале мелькал.
IMHO минимум необходимо знать эти самые C, C++, Java, C# как mainstream approach
и плюс, хотя бы концепции, Python, Nemerle, Delphi 2006, Eiffel, D, Ada 2005, Zonnon и Active Oberon (предложите свои варианты), чтобы участвовать в такой сложной дискуссии, как дизайн языка.
А так я вижу, как описываются грабли C++, и из этого каким-то невообразимо чудесным образом следует рекоммендация Java. Другие, более продвинутые, чем оба этих языка, игнорируются.
Топик-то какой? Философия программирования. Уж здесь-то можно не ограничиваться модными mainstream языками, а сравнивать всё как есть.
Здравствуйте, VladD2, Вы писали:
VD>Ага. Главное чтобы в императивном режиме все было. Ну, чтобы каждый плагин с пол компилятора размером.
Фигня, и в императивном не будет на порядки больше.
E>>В общем, интересный момент в истории
VD>Ага. Люди дошли до конца и поняли, что пришли в тупик. VD>Теперь самое время взят и почитать труды тех кто давно и плодотворно работает с маросами. VD>В принципе решение на поверхности лежит — квазицитирование и паттерн-матчинг. Но боюсь до этого они так и не дойдут и будет как ты говоришь — два Ди.
Ну это у тебя только один вариант, у других людей гораздо больше.
И не понятно каким боком паттерн матчинг к метапрограммированию.
Здравствуйте, FR, Вы писали:
VD>>Ага. Главное чтобы в императивном режиме все было. Ну, чтобы каждый плагин с пол компилятора размером.
FR>Фигня, и в императивном не будет на порядки больше.
Более того, дело даже не в объеме. А в том, что для парсинга какого-нибудь текстового формата (будь то YAML, XML или s-expressions) могут быть готовые D-шные библиотеки (причем не маленькие по объему). И задача состоит в том, что бы при использовании DSL с данным синтаксисом не пришлось эти библиотеки переписывать на compile-time D.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VladD2 wrote: > C>Расскажи им о Nemerle Заодно может и немерлистам от Александреску > C>достанется. > Боже упаси.
Поздно Я уже написал Александреску письмо с вопросом "смотрел ли он
Немерль", он ответил, что "тщательно не смотрел, но хочет в ближайшем
будущем посмотреть, так как его часто упоминают в рассылке D".
Так что готовьтесь к "Modern Programming in Nemerle"
Здравствуйте, Cyberax, Вы писали:
C>Поздно Я уже написал Александреску письмо с вопросом "смотрел ли он C>Немерль", он ответил, что "тщательно не смотрел, но хочет в ближайшем C>будущем посмотреть, так как его часто упоминают в рассылке D".
Мля, спасибов вам с Хроповым. Боюсь, что через месяцом немерловая конфа превратится в клуб веселых и находчивых.
C>Так что готовьтесь к "Modern Programming in Nemerle"
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Фигня, и в императивном не будет на порядки больше.
FR>И не понятно каким боком паттерн матчинг к метапрограммированию.
Интересно, а с чего бы тебе было это понятно? Ты пытался сделать свою метасистему? Вот я пытался и для меня необходимость патетрн-матчинга очевидна. Паттерн-матчинг решает проблемы поиска и декомпозиции в коде. Без него даже простые задачи превращаются в горы запутанного кода. Есть, правда, алтернатива — движок запросов по АСТ, но это по сути то же самое. В R# был именно движок запросов, только он был не так гладко интергрирован в базовый язык и выполнялся в режиме интерпретации. Оба фактора большие минусы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Более того, дело даже не в объеме. А в том, что для парсинга какого-нибудь текстового формата (будь то YAML, XML или s-expressions) могут быть готовые D-шные библиотеки (причем не маленькие по объему). И задача состоит в том, что бы при использовании DSL с данным синтаксисом не пришлось эти библиотеки переписывать на compile-time D.
А, ну, тогда конечно. Ждаем Ди-билиотек уровеня Хаскелевского комбинаторного Парсека. Хотя боюсь, ты мой юмор не поймешь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Фигня, и в императивном не будет на порядки больше.
VD>
FR>>И не понятно каким боком паттерн матчинг к метапрограммированию.
VD>Интересно, а с чего бы тебе было это понятно? Ты пытался сделать свою метасистему? Вот я пытался и для меня необходимость патетрн-матчинга очевидна. Паттерн-матчинг решает проблемы поиска и декомпозиции в коде. Без него даже простые задачи превращаются в горы запутанного кода. Есть, правда, алтернатива — движок запросов по АСТ, но это по сути то же самое. В R# был именно движок запросов, только он был не так гладко интергрирован в базовый язык и выполнялся в режиме интерпретации. Оба фактора большие минусы.
не смотрел? Так как раз рассматриваются разные подходы декомпозиции, через визиторы, тайпкейсы, тайпкасты, кейсклассы и экстракторы (по сути паттерн-матчинг в Scala). Интересно было бы узнать насколько паттерн-матчинг Немерле похож на то, что в Скале, и если есть какие-то более интересные фичи Немерле, если они есть.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Фигня, и в императивном не будет на порядки больше.
VD>
Да понятно, тяжелое отравление функциональщиной
FR>>И не понятно каким боком паттерн матчинг к метапрограммированию.
VD>Интересно, а с чего бы тебе было это понятно? Ты пытался сделать свою метасистему? Вот я пытался и для меня необходимость патетрн-матчинга очевидна. Паттерн-матчинг решает проблемы поиска и декомпозиции в коде. Без него даже простые задачи превращаются в горы запутанного кода. Есть, правда, алтернатива — движок запросов по АСТ, но это по сути то же самое. В R# был именно движок запросов, только он был не так гладко интергрирован в базовый язык и выполнялся в режиме интерпретации. Оба фактора большие минусы.
Патерн матчинг как бы он не был удобен никакого отношения к метасистеме не имеет, ее прекрасно можно сделать как с ним так и без него.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>Более того, дело даже не в объеме. А в том, что для парсинга какого-нибудь текстового формата (будь то YAML, XML или s-expressions) могут быть готовые D-шные библиотеки (причем не маленькие по объему). И задача состоит в том, что бы при использовании DSL с данным синтаксисом не пришлось эти библиотеки переписывать на compile-time D.
VD>А, ну, тогда конечно. Ждаем Ди-билиотек уровеня Хаскелевского комбинаторного Парсека. Хотя боюсь, ты мой юмор не поймешь.
я его тоже не понял, но есть jparsec и parsec-like библиотека в boost. последняя построена на базе библиотеки ленивых вычислений
не смотрел? Так как раз рассматриваются разные подходы декомпозиции, через визиторы, тайпкейсы, тайпкасты, кейсклассы и экстракторы (по сути паттерн-матчинг в Scala). Интересно было бы узнать насколько паттерн-матчинг Немерле похож на то, что в Скале, и если есть какие-то более интересные фичи Немерле, если они есть.
Паттерн-матчинг в Немерле похож на то что есть в Скале. Скала развивает идею паттерн-мачинага на ООП-типы. В Немерле реализация по проще, но тоже есть мысли на счет универсальной реализации. А вообще весь паттерн-матчинг растет из ML-я. Так что не удивительно, что паттерн-матчинг ОКамла, Хаскеля, Скалы и Немеля похожи. Различаюся только детали.
ЗЫ
Объясни мне зачем ради этих слов был так соверквотить? Должно же быть какое-то увежение к тем кто будет тебя читать?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Да понятно, тяжелое отравление функциональщиной
А я и не знал, что у тебя такие проблемы. Быват. Не расстраивайся.
FR>Патерн матчинг как бы он не был удобен никакого отношения к метасистеме не имеет, ее прекрасно можно сделать как с ним так и без него.
Извини, но это в тебе говорит отсуствие опыта. Я в общем, то уже все сказал. Повторяться не буду. Верь во что хочешь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
FR>>Патерн матчинг как бы он не был удобен никакого отношения к метасистеме не имеет, ее прекрасно можно сделать как с ним так и без него.
VD>Извини, но это в тебе говорит отсуствие опыта. Я в общем, то уже все сказал. Повторяться не буду. Верь во что хочешь.
Понятно, опять пошла неадекватность, ладно разговор прекращаю.
Здравствуйте, FR, Вы писали:
FR>Патерн матчинг как бы он не был удобен никакого отношения к метасистеме не имеет, ее прекрасно можно сделать как с ним так и без него.
Проблема в выделенном. В принципе, да, прямого отношения к метасистеме паттерн матчинг не имеет, но без него прекрасно у тебя ничего не получится. Получится груда запутанного, сложно понимаемого кода, что сделает порог вхождения недосягаемым и вся идея потеряет смысл. Т.е. ПМ сам по себе к метасистеме отношения не имеет, но она без него не живёт.
Если нам не помогут, то мы тоже никого не пощадим.
VD>Паттерн-матчинг в Немерле похож на то что есть в Скале. Скала развивает идею паттерн-мачинага на ООП-типы. В Немерле реализация по проще, но тоже есть мысли на счет универсальной реализации. А вообще весь паттерн-матчинг растет из ML-я. Так что не удивительно, что паттерн-матчинг ОКамла, Хаскеля, Скалы и Немеля похожи. Различаюся только детали.
а у ML — из пролога, хотя и в сильно обрезанном виде
Здравствуйте, BulatZiganshin, Вы писали:
E>>>Более того, дело даже не в объеме. А в том, что для парсинга какого-нибудь текстового формата (будь то YAML, XML или s-expressions) могут быть готовые D-шные библиотеки (причем не маленькие по объему). И задача состоит в том, что бы при использовании DSL с данным синтаксисом не пришлось эти библиотеки переписывать на compile-time D.
VD>>А, ну, тогда конечно. Ждаем Ди-билиотек уровеня Хаскелевского комбинаторного Парсека. Хотя боюсь, ты мой юмор не поймешь.
BZ>я его тоже не понял, но есть jparsec и parsec-like библиотека в boost. последняя построена на базе библиотеки ленивых вычислений
jparsec вообще не видел. Думаю какя-то фигня. boost содержит только Спирит — это построители внешних парсеров. Помочь в создании внутненних DSL он не в силах.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если они создавались не в рамках одного проекта, то вряд ли могли взаимстовать идеи друг у друга. В те времена Интеренета и привычки делать все ОпенСорсом небыло.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
OCTAGRAM,
OCT>Мда уж. Такое чувство, что разговор о языках сводится к не лучшим их представителям (C, C++, Java, C#) С таким скудным кругозором едва ли до чего полезного можно будет договориться.
OCT>Весь топик пока не прочитал, D только видел, где-то в начале мелькал.
Не читали, но осужаете? Здорово! Однако Вы не останавливайтесь — я вам гарантирую — Вы встретите упоминания о гораздо большем количестве языков. А если глянуть в rsdn.ru/forum/?group=decl, то может оказаться, что людям известны не только C*|Java.
OCT>Топик-то какой? Философия программирования. Уж здесь-то можно не ограничиваться модными mainstream языками, а сравнивать всё как есть.
Нет, Философия программирования — это раздел форума. А топик называется "сложный язык для сложных программ". Можете завести новый топик, если есть что сказать.
>boost содержит только Спирит — это построители внешних парсеров. Помочь в создании внутненних DSL он не в силах.
если ты имеешь в виду, что эти парсеры не может применять сам компилятор, то да. тут шансы есть только у ghc — parsec+template haskell+чтение данных из внешнего файла
но ведь можно применять и 2-stage scheme — сначала компилируем DSL в промежуточный язык, зтем компилируем этот apsr/ кстати, хаскел в таком режиме достаточно популярен, при этом прогпрамму можно сгенерить и сишную
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, FR, Вы писали:
FR>>Патерн матчинг как бы он не был удобен никакого отношения к метасистеме не имеет, ее прекрасно можно сделать как с ним так и без него.
IT>Проблема в выделенном. В принципе, да, прямого отношения к метасистеме паттерн матчинг не имеет, но без него прекрасно у тебя ничего не получится. Получится груда запутанного, сложно понимаемого кода, что сделает порог вхождения недосягаемым и вся идея потеряет смысл. Т.е. ПМ сам по себе к метасистеме отношения не имеет, но она без него не живёт.
И ты и Влад подразумеваете только один способ построения метасистемы работу с кусками AST, да в таком случае паттерн матчинг очень облегчает жизнь, но есть много других метасистем, где как раз можно прекрасно обходится без него. Да даже в лисповских макросах которые тоже по сути работа с AST полезность паттерн матчинга сомнительна.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>а у ML — из пролога, хотя и в сильно обрезанном виде
VD>Пролог создан в 1972 г. (http://en.wikipedia.org/wiki/Prolog) VD>ML создан в 1973 г. (http://en.wikipedia.org/wiki/ML_programming_language)
VD>Если они создавались не в рамках одного проекта, то вряд ли могли взаимстовать идеи друг у друга. В те времена Интеренета и привычки делать все ОпенСорсом небыло.
вполне возможно, что Рефал позаимстовавл эту идею у языка Маркова, но дополнил её структурой выражения, а затем ML или напрямую, или через Пролог позаимствовал её и применил к алгебраическим типам данных
FR>>Рефал раньше появился в 68 http://en.wikipedia.org/wiki/Refal
BZ>вполне возможно, что Рефал позаимстовавл эту идею у языка Маркова, но дополнил её структурой выражения, а затем ML или напрямую, или через Пролог позаимствовал её и применил к алгебраическим типам данных
Ну рефал во многом и есть марковские замены оформленные в виде языка программирования
BZ>>вполне возможно, что Рефал позаимстовавл эту идею у языка Маркова, но дополнил её структурой выражения, а затем ML или напрямую, или через Пролог позаимствовал её и применил к алгебраическим типам данных
FR>Ну рефал во многом и есть марковские замены оформленные в виде языка программирования
я это и имею в виду. собственно марковский — тоже ЯП
Здравствуйте, IT, Вы писали:
IT>Проблема в выделенном. В принципе, да, прямого отношения к метасистеме паттерн матчинг не имеет, но без него прекрасно у тебя ничего не получится. Получится груда запутанного, сложно понимаемого кода, что сделает порог вхождения недосягаемым и вся идея потеряет смысл. Т.е. ПМ сам по себе к метасистеме отношения не имеет, но она без него не живёт.
Здравствуйте, IT, Вы писали:
IT>Проблема в выделенном. В принципе, да, прямого отношения к метасистеме паттерн матчинг не имеет, но без него прекрасно у тебя ничего не получится. Получится груда запутанного, сложно понимаемого кода, что сделает порог вхождения недосягаемым и вся идея потеряет смысл. Т.е. ПМ сам по себе к метасистеме отношения не имеет, но она без него не живёт.
Глупости какие. Твоё утверждение опровергается простейшим примером — в ST есть метасистема, но нет сопоставлений с образцом.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>>>вполне возможно, что Рефал позаимстовавл эту идею у языка Маркова, но дополнил её структурой выражения, а затем ML или напрямую, или через Пролог позаимствовал её и применил к алгебраическим типам данных
FR>>Ну рефал во многом и есть марковские замены оформленные в виде языка программирования
BZ>я это и имею в виду. собственно марковский — тоже ЯП
Ну марковский скорее ближе к абстрактной машине тьюринга. Хотя конечно его в отличии от машины и как язык можно использовать.
Здравствуйте, BulatZiganshin, Вы писали:
FR>>Ну марковский скорее ближе к абстрактной машине тьюринга.
BZ>ничего общего, только то, что его изобрели для тех же целей. как и лямбда-исчисление
Я имел в виду что марковские алгорифмы это тоже самое что и машина тьюринга (математики вроде доказали их эквивалентность), то есть абстрактное математическое понятие на базе которого можно и язык программирования сделать. Вообще если грубо императивные языки идут от машины тьюринга, функциональные от черчевских рекурсивных функций, ну а рефал от марковских алгоритмов.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, BulatZiganshin, Вы писали:
FR>>>Ну марковский скорее ближе к абстрактной машине тьюринга.
BZ>>ничего общего, только то, что его изобрели для тех же целей. как и лямбда-исчисление
FR>Я имел в виду что марковские алгорифмы это тоже самое что и машина тьюринга (математики вроде доказали их эквивалентность), то есть абстрактное математическое понятие на базе которого можно и язык программирования сделать. Вообще если грубо императивные языки идут от машины тьюринга, функциональные от черчевских рекурсивных функций, ну а рефал от марковских алгоритмов.
вот-вот. поэтому у императивных языков больше сходства с машиной Поста, нежели скажем с рефалом
Здравствуйте, FR, Вы писали:
AVK>>Те чего, думаешь производители приставок на железках зарабатывают?
FR>Нет, ms вобще раньше ниже себестоимости раздавал, но чем больше железок проданно тем больше у них шансов заработать.
FR>>Нет, ms вобще раньше ниже себестоимости раздавал, но чем больше железок проданно тем больше у них шансов заработать.
AVK>Но тогда считать надо в штуках.
Здравствуйте, FR, Вы писали:
FR>>>Нет, ms вобще раньше ниже себестоимости раздавал, но чем больше железок проданно тем больше у них шансов заработать.
AVK>>Но тогда считать надо в штуках.
FR>Не понял в каких штуках?
Видишь ли, приставки разных производителей стоят по разному. Сильно по разному, Поэтому, если хочешь оценить рынок сбыта игр,оценивать надо не сумму денег, а количество приставок.
AVK>Видишь ли, приставки разных производителей стоят по разному. Сильно по разному, Поэтому, если хочешь оценить рынок сбыта игр,оценивать надо не сумму денег, а количество приставок.
Здравствуйте, FR, Вы писали:
FR>И ты и Влад подразумеваете только один способ построения метасистемы работу с кусками AST, да в таком случае паттерн матчинг очень облегчает жизнь, но есть много других метасистем, где как раз можно прекрасно обходится без него. Да даже в лисповских макросах которые тоже по сути работа с AST полезность паттерн матчинга сомнительна.
Очень хотелось бы кроме голословных утверждений посмотреть какой-нибудь небольшой пример, чтобы оценить всю мощь другого подхода.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Глупости какие. Твоё утверждение опровергается простейшим примером — в ST есть метасистема, но нет сопоставлений с образцом.
Метасистема есть даже в C#. С помощью эмита, bltoolkit'а и такой-то матери я могу делать практически всё. Вопрос лишь в трудозатратах и пределеах возможностей. Про метасистему ST с удовольствием бы чего-нибудь почитал научно популярного, чтобы оценить простоту и мощь.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Quintanar, Вы писали:
Q>Там все как всегда — только s-выражения. Но, поскольку они просты по своей структуре, нужда в паттерн матчинге не столь очевидна.
А когда она очевидна? По моему, всё таки паттерн-матчинг не настолько важная вещь как её разрисовавыют на рсдн. Я вот списки в Хаскеле использую часто, а паттерн матчинг над ними нет, т.к. стандартные функции над списком представляют гораздо более мощный интерфейс.
L>А когда она очевидна? По моему, всё таки паттерн-матчинг не настолько важная вещь как её разрисовавыют на рсдн. Я вот списки в Хаскеле использую часто, а паттерн матчинг над ними нет, т.к. стандартные функции над списком представляют гораздо более мощный интерфейс.
имхо Влад как обычно превозносит до небес то, чем Немерле отличается от явы/с#. был бы там playching shatterle — он бы и в нм души не чаял
Здравствуйте, lomeo, Вы писали:
L>А когда она очевидна? По моему, всё таки паттерн-матчинг не настолько важная вещь как её разрисовавыют на рсдн. Я вот списки в Хаскеле использую часто, а паттерн матчинг над ними нет, т.к. стандартные функции над списком представляют гораздо более мощный интерфейс.
Паттерн-матчинг нужен всегда, когда надо извлекать значения из сложных структур данных (более сложных чем int). Хотя бы с той точки зрения, что не надо писать горы if'ов. В том же Лиспе постоянно можно видеть ступенчатые проверки типов и извлечения значений:
Здравствуйте, BulatZiganshin, Вы писали:
BZ>имхо Влад как обычно превозносит до небес то, чем Немерле отличается от явы/с#.
Да если бы только Влад. Я как то тоже самое сказал, так мне кучу минусов понаставили. Ну, нравится людям паттерн-матчинг, а я говорю, что есть вещи вкуснее, конечно, кому понравится?
BZ>был бы там playching shatterle — он бы и в нм души не чаял
[]
BZ>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет
что-что, простите? Вы не опечатались? Так вот почему вы его не любите!
Если серьезно, то придумать писать трэдсейфные конструкторы копирования — это че надо курить или пить или колоть? Я в ауте...
Здравствуйте, Quintanar, Вы писали:
Q>Паттерн-матчинг нужен всегда, когда надо извлекать значения из сложных структур данных (более сложных чем int).
Я постараюсь описать своё имхо. Я согласен с тем, что после описания нашего типа данных (например какого нибудь Map), нам нужно описать его интерфейс в виде функций put/get и т.д. Все они гораздо проще записываются с помощью паттерн матчинга, да. После чего потроха этой структуры можно закрыть — в дальнейшей работе функций, и особенно функций высшего порядка, работающих над этим типом более чем достаточно.
Т.е. если мы работаем с чьим-то типом данных, обычно (часто!) паттерн-матчинг по этой структуре не нужен. Для своего типа данных — да, обычно нужен.
Извлечение же значений имеет какую то цель, которую часто можно достичь другими средствами. Пример — какой нибудь перебор, трансформация, изменение одного значения.
Если же стоит вопрос о выборке одного поля, то селектор для сложной структуры удобнее паттерн-матчинга.
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, BulatZiganshin, Вы писали:
КЛ>[]
BZ>>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет
КЛ>что-что, простите? Вы не опечатались? Так вот почему вы его не любите!
КЛ>Если серьезно, то придумать писать трэдсейфные конструкторы копирования — это че надо курить или пить или колоть? Я в ауте...
я в терминах ошибся поскольку эта область от меня далека. суть дела в том, что даже конструктор значений становится такой штукой, которую без хороших знаний языка не напишешь. для того, чтобы понять, насколько это смешноЮ надо прсто знать один из языков в algebraic data types
Здравствуйте, Константин Л., Вы писали:
BZ>>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет
КЛ>что-что, простите? Вы не опечатались? Так вот почему вы его не любите!
А что тебя так удивляет?
Возьмем например всеми любимый boost::intrusive_ptr
его конструктор компирования не является потокобезопасным.
Удивлен?
Объясняю:
Если в точке !!! произойдет переключения потока и в это время в другом потоке случится присваивание объекту на который ссылается rhs и этот объект держал последнею ссылку то когда поток переключится обратно в p_ окажется указатель на удаленный объект.
Все! Приехали.
У меня одно такое место есть. Поставил там mutex.
КЛ>Если серьезно, то придумать писать трэдсейфные конструкторы копирования — это че надо курить или пить или колоть? Я в ауте...
Оно и видно.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, Константин Л., Вы писали:
КЛ>>Здравствуйте, BulatZiganshin, Вы писали:
КЛ>>[]
BZ>>>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет
КЛ>>что-что, простите? Вы не опечатались? Так вот почему вы его не любите!
КЛ>>Если серьезно, то придумать писать трэдсейфные конструкторы копирования — это че надо курить или пить или колоть? Я в ауте...
BZ>читай http://rsdn.ru/Forum/Message.aspx?mid=2315912&only=1
BZ>я в терминах ошибся поскольку эта область от меня далека. суть дела в том, что даже конструктор значений становится такой штукой, которую без хороших знаний языка не напишешь. для того, чтобы понять, насколько это смешноЮ надо прсто знать один из языков в algebraic data types
Да ты не в терминах ошибся. Ты ошибся тогда, когда принял решение написать о языке, которого, судя по всему, совсем не знаешь. И опять говоришь лабуду (выд.). Прости, конечно, но не пора ли говорить о тех областях, которые для тебя близки? Я уверен на 100%, что никто из знающих с++ людей не пишут потокобезопасные конструкторы копирования. "потокобезопасный конструктор копирования" как должен отсутствовать как термин. Я надеюсь, с++-ники меня поняли.
[]
WH>его конструктор компирования не является потокобезопасным.
WH>Удивлен?
представь себе, нет.
WH>Объясняю:
ты тут всех за идиотов держишь?
[]
WH>Все! Приехали.
Приехал ты, тк ты используешь его НЕПРАВИЛЬНО. Как правильно — объяснять не буду.
WH>У меня одно такое место есть. Поставил там mutex.
КЛ>>Если серьезно, то придумать писать трэдсейфные конструкторы копирования — это че надо курить или пить или колоть? Я в ауте... WH>Оно и видно.
WolfHound wrote: > Если в точке !!! произойдет переключения потока и в это время в другом > потоке случится присваивание объекту на который ссылается rhs и этот > объект держал последнею ссылку то когда поток переключится обратно в p_ > окажется указатель на удаленный объект. > Все! Приехали.
Пример плохой. У нас тут самый обычный race condition —
несинхронизированая работа с объектом. То что при этом у нас получится
premature deletion — это уже просто детали.
Здравствуйте, Константин Л., Вы писали:
КЛ>Приехал ты, тк ты используешь его НЕПРАВИЛЬНО. Как правильно — объяснять не буду.
О великий гуру! Свет всего сущего! Снизойди до убогого! Просвети меня не разумного! Как решить призренную задачку недостойную внимания такого великого программиста как ты!
Призренная задачка: Нужно расшарить неизменяемый объект (карта кластера) между потоками (Потоков много. Машина 4х процессорная.). Причем этот объект иногда обновляется (модифицировать по месту нельзя ибо будет нарушена целостность транзакции да и всеравно придется все внутренности объекта синхронизировать короче проблем будет очень много). При старте транзакции его нужно каждый раз перезапрашивать из централизованного хранилища. Просто удалить объект нельзя ибо его еще могут использовать запросившие рание потоки.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Константин Л., Вы писали:
КЛ>>Приехал ты, тк ты используешь его НЕПРАВИЛЬНО. Как правильно — объяснять не буду. WH>О великий гуру! Свет всего сущего! Снизойди до убогого! Просвети меня не разумного! Как решить призренную задачку недостойную внимания такого великого программиста как ты!
WH>Призренная задачка: Нужно расшарить неизменяемый объект (карта кластера) между потоками (Потоков много. Машина 4х процессорная.). Причем этот объект иногда обновляется (модифицировать по месту нельзя ибо будет нарушена целостность транзакции да и всеравно придется все внутренности объекта синхронизировать короче проблем будет очень много). При старте транзакции его нужно каждый раз перезапрашивать из централизованного хранилища. Просто удалить объект нельзя ибо его еще могут использовать запросившие рание потоки.
процессоры продать. деньгит пропить. буьтылки сдать. на вырученные деньги купить любую толковую книжку по потокам и не морочить голову великому гуру
Здравствуйте, Cyberax, Вы писали:
C>Пример плохой. У нас тут самый обычный race condition — несинхронизированая работа с объектом. То что при этом у нас получится premature deletion — это уже просто детали.
Тем не мение тут нужен либо внешний mutex либо конструктор копирования и оператор присваивания написанные в расчете на работу в разных потоках.
В системах с GC (если не вспоминать про того жутика у которого запись/чтение указателей не атомарно) такой проблемы нет.
А вобще в данном случае я наверное утечку памяти сделаю. Всеравно конфигурация кластера меняется реже чем обновляется ПО. Да и информация эта занимает всего несколько килобайт памяти.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, BulatZiganshin, Вы писали:
BZ>процессоры продать. деньгит пропить. буьтылки сдать. на вырученные деньги купить любую толковую книжку по потокам и не морочить голову великому гуру
А если серьезно есть ли варианты кроме того чтобы общию ссылку лочить?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Константин Л., Вы писали:
КЛ>>Приехал ты, тк ты используешь его НЕПРАВИЛЬНО. Как правильно — объяснять не буду. WH>О великий гуру! Свет всего сущего! Снизойди до убогого! Просвети меня не разумного! Как решить призренную задачку недостойную внимания такого великого программиста как ты!
да ладно тебе. Просто зачем ждать от класса того, для чего он не предназначен? Извини, если до этого ответил заносчиво, но и ты не был мил
WH>Призренная задачка: Нужно расшарить неизменяемый объект (карта кластера) между потоками (Потоков много. Машина 4х процессорная.). Причем этот объект иногда обновляется (модифицировать по месту нельзя ибо будет нарушена целостность транзакции да и всеравно придется все внутренности объекта синхронизировать короче проблем будет очень много). При старте транзакции его нужно каждый раз перезапрашивать из централизованного хранилища. Просто удалить объект нельзя ибо его еще могут использовать запросившие рание потоки.
просто есть типы (читай классы), которые не нуждаются во внутренней потокобезопасности (т.е. написании тех самых thread-safe copy ctors), а должны лочиться снаружи. И то, что ты поставил мьютекс снаружи, есть правильно.
В твоей задачке недостаточно данных для меня.
Я вместо написания этих thread-safe copy ctors использую часто такой хэлпер:
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Cyberax, Вы писали:
C>>Пример плохой. У нас тут самый обычный race condition — несинхронизированая работа с объектом. То что при этом у нас получится premature deletion — это уже просто детали. WH>Тем не мение тут нужен либо внешний mutex либо конструктор копирования и оператор присваивания написанные в расчете на работу в разных потоках. WH>В системах с GC (если не вспоминать про того жутика у которого запись/чтение указателей не атомарно) такой проблемы нет.
WH>А вобще в данном случае я наверное утечку памяти сделаю. Всеравно конфигурация кластера меняется реже чем обновляется ПО. Да и информация эта занимает всего несколько килобайт памяти.
Здравствуйте, BulatZiganshin, Вы писали:
WH>>А если серьезно есть ли варианты кроме того чтобы общию ссылку лочить? BZ>использовать сообщения и отдельный тред который из обрабатывает?
Это в С++ то? Я уж лучше мутексом.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
LCR> А если глянуть в rsdn.ru/forum/?group=decl, то может оказаться, что людям известны не только C*|Java.
Есть подозрение что достаточно взять любую ветку из философии количеством сообщений более 800 и увидеть там
1) Static vs dynamic
2) All vs c++
3) Nemerle vs all
4) А вот монады ..
5) J. просто J
6) Упоминание об языке с надежностью 99.9999%
7) Советы пойти учить BF и Whitespace
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, BulatZiganshin, Вы писали:
WH>>>А если серьезно есть ли варианты кроме того чтобы общию ссылку лочить? BZ>>использовать сообщения и отдельный тред который из обрабатывает? WH>Это в С++ то? Я уж лучше мутексом.
в C++ наверно вообще тружно что-то придумать. возможно, подойдёт отдавать процессу текущее значение, а при модификации создавать новое? или так фактически уже и делается?
Здравствуйте, Quintanar, Вы писали:
IT>>А как там?
Q>Там все как всегда — только s-выражения. Но, поскольку они просты по своей структуре, нужда в паттерн матчинге не столь очевидна.
Можно примерчик или ссылочку на примерчие? Иначе мне сложно будет убедится в справедливости твоего высказывания.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>если ты имеешь в виду, что эти парсеры не может применять сам компилятор, то да. тут шансы есть только у ghc — parsec+template haskell+чтение данных из внешнего файла
Именно это и имею. Если внимательно читать дискуссию, то станет ясно, что речь идет о встроеных DSL-ях.
Внешний файл, кстати, тоже не катит. Это уже не встроенный ДСЛ, а скорее внешний.
BZ>но ведь можно применять и 2-stage scheme — сначала компилируем DSL в промежуточный язык, зтем компилируем этот apsr/ кстати, хаскел в таком режиме достаточно популярен, при этом прогпрамму можно сгенерить и сишную
Это очень сложная схема и в большинстве слуючае на нее просто не решаются. Создание независимого языка — это огромный труд. Его парсинг это только часть работы. Во встроенных DSL-ях ты можешь использовать возможности основного компилятора, что сильно упрощает решение проблемы.
Взять хотя бы недавнее осбуждение реализацию паттерна "Абстрактная фабрика". Как оказалось встренными средствами качественно ее можно легко решить только на Немерле (С++ и Ди позволили создать только сильно ограниченное решение). А создание внешнего DSL-я для данной задачи вообще бессмысленно. Ведь без анализа исходного кода это просто невозможно сделать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>в C++ наверно вообще тружно что-то придумать.
А некоторые не будем показывать пальцем кричат что в С++ все хорошо
Я вобще мечтаю о чемто типа каналов из сингулярити. Они бы мне очень сильно жизнь упростили.
Особенно мне нравится то что там можно передовать end-point одного канала по другому.
BZ>возможно, подойдёт отдавать процессу текущее значение, а при модификации создавать новое? или так фактически уже и делается?
Именно так я и делаю. Иного решения чтобы не порушить все я не придумал.
Но есть проблема с временем жизни этого объекта (он довольно большой... строки, таблици...).
Тут 2 варианта:
1) Лочить расшаренную ссылку для того чтобы избежать преждевременного уменьшения счетчика ссылок. Я так сейчас и делаю.
2) Забить. Ибо утечка нескольких килобайт раз в несколько месяцев при 8 гигах оперативки... при том что ПО на сервере меняется чаще...
BZ>посмотри ещё на всякий случай BZ>The Little Book of Semaphores, Allen B. Downey [http://greenteapress.com/semaphores/downey05semaphores.pdf]
Спасибо. Посмотрю.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Quintanar, Вы писали:
IT>>>А как там?
Q>>Там все как всегда — только s-выражения. Но, поскольку они просты по своей структуре, нужда в паттерн матчинге не столь очевидна.
IT>Можно примерчик или ссылочку на примерчие? Иначе мне сложно будет убедится в справедливости твоего высказывания.
WolfHound wrote: > C>Пример плохой. У нас тут самый обычный race condition — > несинхронизированая работа с объектом. То что при этом у нас получится > premature deletion — это уже просто детали. > Тем не мение тут нужен либо внешний mutex либо конструктор копирования и > оператор присваивания написанные в расчете на работу в разных потоках.
Проблема возникнет только если последняя ссылка на умный указатель,
который передается по ссылке (!), находится в другом потоке. Весьма
необычная ситуация, согласись.
Проще всего ее решить, передавая умный указатель в поток по значению.
Ну и естественно, нужно использовать interlocked-функции для addref/release.
WolfHound wrote: > Призренная задачка: Нужно расшарить неизменяемый объект (карта кластера) > между потоками (Потоков много. Машина 4х процессорная.). Причем этот > объект иногда обновляется (модифицировать по месту нельзя ибо будет > нарушена целостность транзакции да и всеравно придется все внутренности > объекта синхронизировать короче проблем будет очень много). При старте > транзакции его нужно каждый раз перезапрашивать из централизованного > хранилища. Просто удалить объект нельзя ибо его еще могут использовать > запросившие рание потоки.
А передавать объект в транзакцию по значению нельзя? Тем более, что он
всего несколько килобайт. Или передавать указатель на него по значению.
Ой, да defmacro в гугле — и вперёд! Примеров полно Только я объясняю это не простотой s-выражений, как уважаемый Quintanar, а тем, что паттерн-матчинг нужен большей частью на очень низком уровне разработки типа.
Здравствуйте, Cyberax, Вы писали:
C>Проблема возникнет только если последняя ссылка на умный указатель, который передается по ссылке (!), находится в другом потоке. Весьма необычная ситуация, согласись.
Я параноик. Мне по работе положено. Тебе кстати тоже.
C>Проще всего ее решить, передавая умный указатель в поток по значению.
Это как?
Вобще у меня такак ситуация:
Есть интерфейс модуля некого многопоточного сервера.
Мой модуль реализует этот интерфейс.
При создании моего модуля я создаю этот самый объект и сохраняю ссылку на нго в своем модуле. Плюс еще некоторое колличество неизменяемых данных.
У этого интерфейса есть метод что-то типа
virtual Result handler(Context* context) = 0;
Этот метод дергается каждый раз когда приходит новый запрос.
Причем он дергается из разных потоков некоторого пула потоков.
Большинство запросов в самом начале копируют к себе ссылку и работают уже с локальной копией.
Но иногда приходит запрос который приводит к пересозданию этого объекта и изменению ссылки в модуле.
Вот из-за этого запроса мне и приходится городить мьютекс вокруг ссылки.
Иначе моя параноя меня загрызет.
C>Ну и естественно, нужно использовать interlocked-функции для addref/release.
Ну это само собой.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Проблема возникнет только если последняя ссылка на умный указатель, > который передается по ссылке (!), находится в другом потоке. Весьма > необычная ситуация, согласись. > Я параноик. Мне по работе положено. Тебе кстати тоже.
Я настолько параноик, что такие ситуации (конкурентный вызов нескольких
методов объекта) заранее себе запрещаю. Плохое влияние Эрланга, однако.
> При создании моего модуля я создаю этот самый объект и сохраняю ссылку > на нго в своем модуле. Плюс еще некоторое колличество неизменяемых данных. > У этого интерфейса есть метод что-то типа > virtual Result handler(Context* context) = 0; > Этот метод дергается каждый раз когда приходит новый запрос. > Причем он дергается из разных потоков некоторого пула потоков.
Сделай mutexex_ptr. Что-то типа:
Обернуть в политики и другие интересные штуки из Александреску по желанию.
> Большинство запросов в самом начале копируют к себе ссылку и работают > уже с локальной копией. > Но иногда приходит запрос который приводит к пересозданию этого объекта > и изменению ссылки в модуле. > Вот из-за этого запроса мне и приходится городить мьютекс вокруг ссылки. > Иначе моя параноя меня загрызет.
А можно ли привязать по объекту-обработчику к каждому из потоков пула?
Здравствуйте, lomeo, Вы писали:
L>Ой, да defmacro в гугле — и вперёд! Примеров полно Только я объясняю это не простотой s-выражений, как уважаемый Quintanar, а тем, что паттерн-матчинг нужен большей частью на очень низком уровне разработки типа.
В Лиспе нет возможности конструировать типы так свободно, как в ML. Нет там повсеместного использования tuple и unions. Поэтому нет необходимости разбирать большие вложенные друг в друга конструкции (кроме списков), а значит нет необходимости в ПМ.
ПМ — это очень удобный способ не писать кучу сравнений и присваиваний руками, поэтому это довольно нужная фича.
Здравствуйте, Cyberax, Вы писали:
C>Я настолько параноик, что такие ситуации (конкурентный вызов нескольких методов объекта) заранее себе запрещаю.
Это данность. Ничего с этим не поделать.
C>Плохое влияние Эрланга, однако.
Был бы это ерланг или любой другой язык со сборкой мусора то и этого вопроса небыло.
Но это С++.
C>Сделай mutexex_ptr. Что-то типа:
хъ C>Обернуть в политики и другие интересные штуки из Александреску по желанию.
Еще один.
Написать обертку не проблема.
Но от мъютекса она всеравно не избавляет.
C>А можно ли привязать по объекту-обработчику к каждому из потоков пула?
А толку? Обновлние карты всеравно никто не отменял.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Плохое влияние Эрланга, однако. > Был бы это ерланг или любой другой язык со сборкой мусора то и этого > вопроса небыло. > Но это С++.
Я не про GC, в Эрланге просто такой ситуации быть не может — мутирующие
объекты там не разделяются между потоками, я у себя сейчас так же делаю.
> C>Обернуть в политики и другие интересные штуки из Александреску по желанию. > Еще один. > Написать обертку не проблема. > Но от мъютекса она всеравно не избавляет.
Ну так от него избавится и не получится при всем желании. Точнее, если
уж совсем извращаться — то можно избавится.
> C>А можно ли привязать по объекту-обработчику к каждому из потоков пула? > А толку? Обновлние карты всеравно никто не отменял.
Так оно всегда будет в одном потоке — так что такие RC просто будут
невозможны.
Здравствуйте, Cyberax, Вы писали:
C>Я не про GC, в Эрланге просто такой ситуации быть не может — мутирующие объекты там не разделяются между потоками, я у себя сейчас так же делаю.
Так и я не шарю без крайней необходимости.
Сама карта не изменяемая.
Меняется только ссылка на нее.
C>Ну так от него избавится и не получится при всем желании. Точнее, если уж совсем извращаться — то можно избавится.
Я уж лучше мъютексом.
C>Так оно всегда будет в одном потоке — так что такие RC просто будут невозможны.
Так мне приходит одно сообщение о том что нужно обновить карту.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Я не про GC, в Эрланге просто такой ситуации быть не может — > мутирующие объекты там не разделяются между потоками, я у себя сейчас > так же делаю. > Так и я не шарю без крайней необходимости. > Сама карта не изменяемая. > Меняется только ссылка на нее.
Ссылка — это тоже изменяемый объект.
> C>Так оно всегда будет в одном потоке — так что такие RC просто будут > невозможны. > Так мне приходит одно сообщение о том что нужно обновить карту.
И обновляй — в это время никакие другие методы этого объекта исполняться
не будут, значит и RC отсутствует. А если у тебя и так пул потоков — то
почему бы так не сделать?
Кстати, именно такая модель используется в EJB в Java — там бины
привязаны к потоку из пула.
Здравствуйте, FR, Вы писали:
FR>И ты и Влад подразумеваете только один способ построения метасистемы работу с кусками AST, да в таком случае паттерн матчинг очень облегчает жизнь, но есть много других метасистем, где как раз можно прекрасно обходится без него. Да даже в лисповских макросах которые тоже по сути работа с AST полезность паттерн матчинга сомнительна.
1. Про много чистая лож. Я могу насчитать 3 штуки.
2. В любой метасистеме нужны средства композиции и декомпозиции. Мамый хреновый подход в этом плане это императивный (читай традицинной процедурно-ООП-ный).
3. Лисп это а) работа с программой в виде АСТ с теми самиыми квази-цитированиями и б) как раз в макросах для используется сопоставление с обрзцом.
4. Ты будешь смеяться, но метапрограммирование на шаблонах С++ использует ни что иное, как функциональный язык с паттерн-матчингом . И это при том, что в основной части языка С++ нет ни того, ни дргого. Вот такая, мля, силявя.
Так что сомнителен скорее твой опыт в этом вопросе.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Quintanar, Вы писали:
Q>Там все как всегда — только s-выражения. Но, поскольку они просты по своей структуре, нужда в паттерн матчинге не столь очевидна.
Макросы схемы и CL как раз и используют паттерн-матчинг. Просто он там не является штатной частью языка, а реализован средстваи языка. Достаточно поглядеть на то как описываются маросы в той же Схеме и все становится очевидно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
L>>А когда она очевидна? По моему, всё таки паттерн-матчинг не настолько важная вещь как её разрисовавыют на рсдн. Я вот списки в Хаскеле использую часто, а паттерн матчинг над ними нет, т.к. стандартные функции над списком представляют гораздо более мощный интерфейс.
BZ>имхо Влад как обычно превозносит до небес то, чем Немерле отличается от явы/с#. был бы там playching shatterle — он бы и в нм души не чаял
Паттерн-матчинг не выдуман в Немерле. А я излагаю только собственный опыт. Я сам пытался создать метасистему для C# и столкнулся с необъодимостью создания некого декларативного языка запросов для облегчения декомпозиции кода. Когда же я узнал о паттерн-матчинге в паре с квази-цитированием я понл, что это то что нужно.
Конечно могут быть альтернативы, но пока все что я видел или использовал паттерн-матчинг напрямую, или его анлоги. Даже МС в своих кодогенераторах дошле до идеи паттерн-матчинга (хотя отказались от квази-цитирования).
Квази-цитирование используется в:
1. MetaO'Caml, TemplateHaskell, Lisp.
Паттерн-матчинг тоже используется прямо или косвенно во всех успешных метасистемах.
Откровенно говоря я не заню что тут обсуждать то?
Приведите пример метасистемы без паттерн-матчинга и квази-цитирвоания и давайте обсудим ее приемущества. Сразу намек, С++ не приводить. Там как раз паттерн-матчинг используется .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Quintanar, Вы писали:
Q>В Лиспе нет возможности конструировать типы так свободно, как в ML. Нет там повсеместного использования tuple и unions. Поэтому нет необходимости разбирать большие вложенные друг в друга конструкции (кроме списков), а значит нет необходимости в ПМ.
На самом деле есть. И на самом деле даже кое где применяется. Тот же синтаксис with-matrix по сути определяет паттерн. Если бы пришлось выскивать нужные паттерны вручную, то было бы вообще жуть.
И если бы в языке был штатный паттерн-матчинг, то и код бы выглядил бы несколько понятнее.
Q>ПМ — это очень удобный способ не писать кучу сравнений и присваиваний руками, поэтому это довольно нужная фича.
Скажем так, это уменьшат необходимость, но не убирает ее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Глупости какие. Твоё утверждение опровергается простейшим примером — в ST есть метасистема, но нет сопоставлений с образцом.
Это круто! Это их роднит с каменным топором.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Метасистема есть даже в C#. С помощью эмита, bltoolkit'а и такой-то матери я могу делать практически всё. Вопрос лишь в трудозатратах и пределеах возможностей. Про метасистему ST с удовольствием бы чего-нибудь почитал научно популярного, чтобы оценить простоту и мощь.
Увы, что подсказать для быстрого ознакомления я не знаю Может эту презентацию?
Но если в двух словах то... Есть классы, есть метаклассы (как first class object).
Система такая:
obj := Object new. "Создаём объект класса `Object`"
obj class. "=> `Object` - это класс объекта"
obj class class. "=> `Object class` - класс класса объекта. То бишь метакласс. Они неименованы (называются по имени соответствующего класса) и каждый класс-метакласс образуют пару (1-1)"
obj class class class. "=> `Metaclass` - общий класс всех метаклассов"
obj class class class class. "=> `Metaclass class`"
obj class class class class class. "=> `Metaclass`"
Создание новых классов/метаклассов это просто инстантиирование объектов соответствующего класса:
Object new. "Создаём объект класса `Object`"
Metaclass new. "Создаём метакласс"
Компиляция методов объекта производится вызовом метода #compile: у своего класса. Это позволяет переопределить компилятор для любого класса/иерархии. Например, в VisualWorks расширен компилятор классов связанных с FFI.
Сами методы класса лежат в словаре методов класса. Чтобы добавить добавить/заменить метод мы просто ложим в соответствующий словарь объект класса `CompiledMethod`:
Замечу, что можно создавать свои подклассы от CompiledMethod. Например иерархия в VisualWorks:
CompiledMethod
AnnotatedMethod "Метод с аннотациями (в VW они называются 'pragmas')"
MarkedMethod
UserPrimitiveMethod
ExternalMethod "Умеет делать вызов "внешних" функций - FFI"
ProbedCompiledMethod "Машинерия отладчика"
ProbedAnnotatedMethod
Чтобы создать скомпилированный метод можно либо скормить компилятору ST-код, либо создать метод самому или воспользоваться либой.
Вот как выглядит схема класса кода в VW:
Instance Variables:
mclass <Behavior> Класс в контексте которого был скомпилирован код
sourceCode <nil | Integer> Ссылка на исходный код во внешнем файле
bytes <SmallInteger | ByteArray> - байткод специфичный для VW.
(indexed instance variables) <Object> - литералы (индексированный переменные это те, к оторым обращение происходит не по имени, а по номеру).
Теперь чтобы, например, сделать так, чтобы у некоторого объекта был специфический только для этого объекта метод метод, нужно:
а) склонировать класс объекта: `anObject class copy`;
б) заменить метод с определённым именем на новый: `aClass methodDictionary at: #specificMethod put: aSpecificMethod`
в) поменять класс у объекта: `anObject adoptInstance: newClass`.
Или, например, можно ввести подсистему, которая будет базироваться не на классах, а на прототипах.
Можно добавить только, что есть такая штука, как CLOS MOP. Как это принято в Лиспе, там реализовано всё, что только можно придумать Не думаю, что там сопоставление с образцом играет жизненно важную роль.
Здравствуйте, WolfHound, Вы писали:
BZ>>>вплоть до написания thread-safe конструкторов копирования
КЛ>>что-что, простите? Вы не опечатались? Так вот почему вы его не любите!
WH>А что тебя так удивляет? WH>Возьмем например всеми любимый boost::intrusive_ptr WH>
WH>его конструктор компирования не является потокобезопасным.
Документацию по используемым компонентам читать нужно:
1) А кто обещал, что он будет "потокобезопасным"? Где-нибудь в документации это было сказано? (Ответ отрицательный).
2) shared_ptr такие гарантии дает.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, WolfHound, Вы писали:
WH>Тем не мение тут нужен либо внешний mutex либо конструктор копирования и оператор присваивания написанные в расчете на работу в разных потоках. WH>В системах с GC (если не вспоминать про того жутика у которого запись/чтение указателей не атомарно) такой проблемы нет.
Ерунда какая... Конечно, есть. В случае разделения объекта между потоками исполнения копирование объектов там тоже нужно будет делать с учетом возможных race conditions и т.п. (там это обычно называется clone или как-нибудь еще подобным образом из-за отсутствия внятной value семантики).
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Ерунда какая... Конечно, есть. В случае разделения объекта между потоками исполнения копирование объектов там тоже нужно будет делать с учетом возможных race conditions и т.п. (там это обычно называется clone или как-нибудь еще подобным образом из-за отсутствия внятной value семантики).
Мне нужно скопировать ОДИН УКАЗАТЕЛЬ.
В С++ Я вынужден счелкать счетчиком ссылок и из-за этого копирование указателя не атомарно.
В системах с ГЦ копирование ссылки атомарно.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Документацию по используемым компонентам читать нужно:
Я предпочитаю сырци. ПК>1) А кто обещал, что он будет "потокобезопасным"? Где-нибудь в документации это было сказано? (Ответ отрицательный).
А где я говорил что кто-то обещал?
Я просто сказал что иногда это может быть нужным. ПК>2) shared_ptr такие гарантии дает.
А если почитать сырци то ничего что могло бы дать подобные гарантии там не обнаружилось.
Вот посмотри на класс который считает ссылки:
WolfHound,
> ПК> Документацию по используемым компонентам читать нужно:
> Я предпочитаю сырци.
Хотя и не очень эффективный, но вполне рабочий подход для написания одноразового кода.
> ПК> 2) shared_ptr такие гарантии дает.
> А если почитать сырци то ничего что могло бы дать подобные гарантии там не обнаружилось. > <...> > Или я что-то не заметил?
Это я не заметил, что ты пытаешься обращаться к одному и тому же объекту из разных потоков, модифицируя его. Это, естественно, работать не будет. Дальше разговор можно не продолжать, пока не будет приведена здравая причина необходимости отсутствия синхронизации при обращении к модифицируемому разделяемому ресурсу.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> Я предпочитаю сырци. ПК>Хотя и не очень эффективный, но вполне рабочий подход для написания одноразового кода.
Почему одноразового?
И вобще если не смотреть в сырци того что используешь можно нарваться по крупному.
ПК>Это я не заметил, что ты пытаешься обращаться к одному и тому же объекту из разных потоков, модифицируя его. Это, естественно, работать не будет. Дальше разговор можно не продолжать, пока не будет приведена здравая причина необходимости отсутствия синхронизации при обращении к модифицируемому разделяемому ресурсу.
Если все операции с данным объектом атомарны то синхронизация избыточна.
С логической точки зрения boost::intrusive_ptr является ссылкой на объект.
В системах с ГЦ операции с ссылками атомарны. Те синхронизация не нужна.
Операции с boost::intrusive_ptr не атомарны. Те синхронизация нужна.
Именно эта необходимость синхронизации на ровном месте меня несколько раздражает.
Кто тут любит говорить про zerro overhead? А тут целий мъютекс на ровном месте. Да еще и счетчиком ссылок счелкать постоянно надо. А interlocked функции особенно на многопроцессорном железе не дешевы.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Можно добавить только, что есть такая штука, как CLOS MOP. Как это принято в Лиспе, там реализовано всё, что только можно придумать Не думаю, что там сопоставление с образцом играет жизненно важную роль.
Очень похоже сделана эмуляция ООП в JS. Видимо дралось из ST. Но вопрос был немного не об этом. Похоже мы просто запутались в терминологии. Меня прежде всего интересуют возможности метапрограммирования. Как, например, в ST делается (если делается) обработка и преобразование AST или любого другого представления кода/метаданных программы?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, WolfHound, Вы писали:
>>> Я предпочитаю сырци.
ПК>>Хотя и не очень эффективный, но вполне рабочий подход для написания одноразового кода.
WH>Почему одноразового?
Потому что, если полагаться на реализацию вместо published specification, то никаких гарантий того, что использованное поведение останется именно таким, при дальнейшей поддержке кода не будет.
WH>И вобще если не смотреть в сырци того что используешь можно нарваться по крупному.
Тестировать нужно.
ПК>>Это я не заметил, что ты пытаешься обращаться к одному и тому же объекту из разных потоков, модифицируя его. Это, естественно, работать не будет. Дальше разговор можно не продолжать, пока не будет приведена здравая причина необходимости отсутствия синхронизации при обращении к модифицируемому разделяемому ресурсу.
WH>Если все операции с данным объектом атомарны то синхронизация избыточна.
Атомарности операций для отсутствия необходимости синхронизации недостаточно: в общем случае нужен еще memory barrier для устранения эффектов переупорядочивания этих операций.
WH>Кто тут любит говорить про zerro overhead?
Не знаю. До некоторых пор я скорее любил говрить о premature optimization. Теперь подпись окупирована другим.
WH>А тут целий мъютекс на ровном месте.
Т.е. мотивация -- "ускорение"? Это не кажется здравой причиной для отсутствия синхронизации при периодическом перечитывании конфигурации из разделяемого объекта.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Ага, ага. Текстуальня компиляци без единой проверки и без возможности декомпозиции кода.
Ну, так мы дойдем, что и C# обладает охриниельной системой метапрограммирования, так как есть библиотеки компиляции кода на лету и возможность его испонять в рантайме.
В гробу я такие системы метапрограммирования имел.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Quintanar, Вы писали:
VD>>Скромный вопрос... Что есть выделенные фрагменты?
Q>pat & ar — первые два элемента списка. &body body — остаток списка. Т.е Q>
Q>(with-array ((a 0 0) (d 1 1) (i 2 2)) ar
Q> (values a d i))
Q>
Q>pat — pattern = ((a 0 0) (d 1 1) (i 2 2)) Q>ar — array Q>&body = (values a d i)
Не, нет. Как это называется?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
ПК>>Ерунда какая... Конечно, есть. В случае разделения объекта между потоками исполнения копирование объектов там тоже нужно будет делать с учетом возможных race conditions и т.п. (там это обычно называется clone или как-нибудь еще подобным образом из-за отсутствия внятной value семантики). WH>Мне нужно скопировать ОДИН УКАЗАТЕЛЬ. WH>В С++ Я вынужден счелкать счетчиком ссылок и из-за этого копирование указателя не атомарно. WH>В системах с ГЦ копирование ссылки атомарно.
В чем-то Паша прав. Ни C# ни С++ не рассчитаны на многопоточность и в программах на них написанных всегда можно найти тучу мест где можно словить трудно-уловимые ошибки. Хотя конечно сам ЖЦ резко упрощат жизнь. Но по-моему не на столько на сколько нужно для комфортного программирования.
В идиале, я вообще не должен думать о блокировках, гонках и т.п. Тут нужен или фрэйворк или поддержка со стороны языка.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ну, надоело, чесс-слово.
Тебе нужно побуквенное совпадение названия макры? Суть патерн-матчинга, как я уже неоднократно говорил, в двух действиях — деструктинге (разборе списка на составные части) и байдинге.
Или тебе не нравится то, что это макра, а не вколоченная гвоздями сущность?
Здравствуйте, VladD2, Вы писали:
VD>Ага, ага. Текстуальня компиляци без единой проверки и без возможности декомпозиции кода.
Какая текстуальная компиляция? Окстись. Я жу написал, если нужен класс создаём объект и всё. Никакой компиляции вообще.
VD>Ну, так мы дойдем, что и C# обладает охриниельной системой метапрограммирования, так как есть библиотеки компиляции кода на лету и возможность его испонять в рантайме.
Срочно читать мой пост еще раз.
VD>В гробу я такие системы метапрограммирования имел.
Здравствуйте, IT, Вы писали:
IT>Очень похоже сделана эмуляция ООП в JS. Видимо дралось из ST. Но вопрос был немного не об этом. Похоже мы просто запутались в терминологии. Меня прежде всего интересуют возможности метапрограммирования. Как, например, в ST делается (если делается) обработка и преобразование AST или любого другого представления кода/метаданных программы?
Возможно есть действительно недопонимание друг друга.
Вот я показал, как заменить один метод на другой, добавить/удалить метод. Имхо, это именно метапрограммирование и есть. Только оно осуществляется не манипулированием ни АСТ, ни текстуальным представлением программы, а манипулированием теми сущностями, которые есть результат кодогенерации в других языках. То бишь, если в Nemerle тебе, для создания класса нужно произвести манипуляции с AST, то в ST достаточно сделать `Metaclass new`. Всё, наш новый класс можно использовать в программе.
Добавлю, что в ST нет разницы между write time/compile time/run time. Это важное идеологическое отличие от других систем, где все три этапа четко отличимы. Например, когда я в ИДЕ в ST добавляю класс, то он в самом низу создаётся при помощи того же `Metaclass new`. То есть сама ИДЕ метапрограммирует программу.
Что касается инструментария, который работает с исходным кодом (Ref.Browser, напр), то там естественно есть и AST и визиторы . Но назвать это метапрограммированием у меня язык не поворачивается.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Возможно есть действительно недопонимание друг друга.
ANS>Вот я показал, как заменить один метод на другой, добавить/удалить метод. Имхо, это именно метапрограммирование и есть.
Не совсем. Подобное можно сэмулировать даже в С с помощью указателей на функции. В моём понимании метапрограммирование — это программирование программ, которые в свою очередь создают программы. Например, макрос Немерле, анализируя контекст вызова может порождать принципиально разный код. А твой пример — это не более чем манипулирование таблицей виртуальных методов.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
ANS>>Вот я показал, как заменить один метод на другой, добавить/удалить метод. Имхо, это именно метапрограммирование и есть.
IT>Не совсем. Подобное можно сэмулировать даже в С с помощью указателей на функции.
Видимо, имеется в виду, что в С нельзя создать код этих функций.
Здравствуйте, lomeo, Вы писали:
IT>>Не совсем. Подобное можно сэмулировать даже в С с помощью указателей на функции.
L>Видимо, имеется в виду, что в С нельзя создать код этих функций.
Так создание/генерацию кода я как раз нигде и не увидел.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, lomeo, Вы писали:
IT>>>Не совсем. Подобное можно сэмулировать даже в С с помощью указателей на функции.
L>>Видимо, имеется в виду, что в С нельзя создать код этих функций.
IT>Так создание/генерацию кода я как раз нигде и не увидел.
Насколько я понимаю строками Потом даём компилеру. Ну или байткод генерить.
Здравствуйте, lomeo, Вы писали:
IT>>Так создание/генерацию кода я как раз нигде и не увидел.
L>Насколько я понимаю строками Потом даём компилеру. Ну или байткод генерить.
А как быть с декомпозицией кода?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
ANS>>Вот я показал, как заменить один метод на другой, добавить/удалить метод. Имхо, это именно метапрограммирование и есть.
IT>Не совсем. Подобное можно сэмулировать даже в С с помощью указателей на функции. В моём понимании метапрограммирование — это программирование программ, которые в свою очередь создают программы.
Вот смотри. В ST есть объекты (методы и классы это first class objects), которым можно посылать сообщения.
Программирование в ST это последовательное создание нужных объектов — последовательное изменение состояния, которое хранится в образе (image). Когда мы создаём класс в ИДЕ, на самом деле создаётся объект-класс.
Когда мы добавляем метод в наш класс, в этот объект-класс ИДЕ добавляет объект-метод. То есть, чтобы в класс добавить метод, нужно в колекцию методов класса просто положить метод. Что бы создать метод, нужно создать экземпляр класса `CompiledMethod` и напихать в него байт-коды. Байт-коды хранятся в списке в этом объекте. Естественно они специфичны для разных ВМ. Но если учитывать, что в ST-языке есть единственная операция — посылка сообщения, то байткодов много знать не нужно. (Есть даже люди, которые считаю, что ST это ОО-ассемблер). На практике же, компилятор среды обычно выполняет ряд (отключаемых) оптимизаций. Например, код '1000 timesDo: [ ... ]' не компилируется в отправку сообщения, а компилируется непосредственно в цикл. То есть чистота, принесена в угоду практичности. Хотя, если вызвать метод `timesDo:` у объекта-числа через рефлексию, то всё будет работать. Сейчас уже эти оптимизации уже не играют такой важной роли как в 80-х гг.
IT> Например, макрос Немерле, анализируя контекст вызова может порождать принципиально разный код.
Ну, так и любая ST-программа может, например, скомпилировать регэксп непосредственно в ST-байткод. Все манипуляции с кодом, выполняются манипулированием соответствующими объектами. Есть тулзы которые автоматизируют наиболее частые задачи.
IT>А твой пример — это не более чем манипулирование таблицей виртуальных методов.
Почти. Если чуть доработать эту систему, то получится ST-машины. В соответсвии с законом Гринспуна
Здравствуйте, lomeo, Вы писали:
IT>>А как быть с декомпозицией кода?
L>Прости, не понял. Что имеется в виду?
Обсуждаемый в этом топике ПМ используется как раз для декомпозиции кода, т.е. для разложения входного потока AST на составляющие и дальшейшего анализа. Например, вот как раскладывает макрос when входные параметры для реализации дополнительных возможностей, если используется конструкция when (x is something):
Здравствуйте, Andrei N.Sobchuck, Вы писали:
IT>> Например, макрос Немерле, анализируя контекст вызова может порождать принципиально разный код.
ANS>Ну, так и любая ST-программа может, например, скомпилировать регэксп непосредственно в ST-байткод. Все манипуляции с кодом, выполняются манипулированием соответствующими объектами. Есть тулзы которые автоматизируют наиболее частые задачи.
Method wrapper — это уже ход в правильном направлении, но он всё ещё далёк от совершенства. Например, похожий способ используется в BLToolkit для генерации абстрактных и расширения виртуальных методов. Но это лишь способ слепить конфетку из того, что было. Тут не может быть никакого сравнения со штатными, специально заточенными для этого средствами метапрограммирования.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Ну, надоело, чесс-слово. ANS>Тебе нужно побуквенное совпадение названия макры?
Я не об опечатках или не совпадениях. Я о том, что это не фича языка, а андстройка реализованная на макросах.
ANS>Или тебе не нравится то, что это макра, а не вколоченная гвоздями сущность?
Мне не ненравится. Это просто факт. Это не языковая фича, хотя несомненно она есть. Только вот не везде.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Какая текстуальная компиляция? Окстись. Я жу написал, если нужен класс создаём объект и всё. Никакой компиляции вообще.
Какой объект надо создать чтобы реализовать некий метод?
VD>>Ну, так мы дойдем, что и C# обладает охриниельной системой метапрограммирования, так как есть библиотеки компиляции кода на лету и возможность его испонять в рантайме.
ANS>Срочно читать мой пост еще раз.
Срочно в лес.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT> Но это лишь способ слепить конфетку из того, что было. Тут не может быть никакого сравнения со штатными, специально заточенными для этого средствами метапрограммирования.
Моя твоя не понимает.
И ежу понятно, что тулза заточенная на работу с АСТ, должна работать с АСТ лучше, чем та, которой на АСТ наплевать. Но это не делает патерн матчинг средством метапрограммирования. Тем более единственным средством. Я тебе показал как создаются новые классы и методы. Это уже метапрограммирование. Если не нравится уровень абстракции, то его всегда можно повысить при помощи либы. Действительно, стандартных средств доступа к АСТ метода нет. Refactoring Browser, как я уже говорил, для этих целей тащит свою компилятор. Кстати, если очень хочется, то можно добавить в объект-метод переменную, в которой и сохранять АСТ, но я сейчас не представляю зачем это нужно.
Что касается макросов и манипуляций с кодом, то в ST _сознательно_ отказались от этого. (afair, в ST-72 каждый объект сам задавал синтаксис потока сообщений, но возникли проблемы "совместимости" синтаксисов). Для создания новых управляющих конструкций в ST есть блоки. А со всякими хитромакросами из Nemerle может получиться продукт, который превзойдёт Perl по количеству способов достичь чего-то. Но к метапрограммированию это не имеет никакого отношения.
ЗЫ. Ты еще раз обрати внимание на то, что разницы между временем компиляции и временем выполнения в ST нет вообще.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
IT>> Но это лишь способ слепить конфетку из того, что было. Тут не может быть никакого сравнения со штатными, специально заточенными для этого средствами метапрограммирования.
ANS>Моя твоя не понимает.
ANS>И ежу понятно, что тулза заточенная на работу с АСТ, должна работать с АСТ лучше, чем та, которой на АСТ наплевать. Но это не делает патерн матчинг средством метапрограммирования. Тем более единственным средством.
Этого никто и не утверждает. Утверждается другое. А именно, что метапрограммирование (*) не живёт без ПМ.
ANS>Я тебе показал как создаются новые классы и методы. Это уже метапрограммирование.
(*) Как я уже сказал, скорее всего у нас есть нестыковка в терминологии. Возможно это метапрограммирование, но это такое же метапрограммирование, как и программирование ячеек в Excel по сравнением с программированием на тех же плюсах. Т.е. несравнимо другой уровень. Я ничего не имею против такого метапрограммирования, но я не его имею ввиду. Если же тебе хочется оспорить сам термин, то, извини, но мне это не интересно. Хочешь, заведи другой топик.
ANS>Если не нравится уровень абстракции, то его всегда можно повысить при помощи либы. Действительно, стандартных средств доступа к АСТ метода нет. Refactoring Browser, как я уже говорил, для этих целей тащит свою компилятор. Кстати, если очень хочется, то можно добавить в объект-метод переменную, в которой и сохранять АСТ, но я сейчас не представляю зачем это нужно.
С этого надо было начинать.
ANS>Что касается макросов и манипуляций с кодом, то в ST _сознательно_ отказались от этого. (afair, в ST-72 каждый объект сам задавал синтаксис потока сообщений, но возникли проблемы "совместимости" синтаксисов). Для создания новых управляющих конструкций в ST есть блоки. А со всякими хитромакросами из Nemerle может получиться продукт, который превзойдёт Perl по количеству способов достичь чего-то. Но к метапрограммированию это не имеет никакого отношения.
Это всё твои домыслы. Может быть приведёт к перлу, а может быть не приведёт. Лично для меня уровень метапрограммирования, предоставляемый Немерле вполне востребован, т.к. более низкие уровни я уже прошёл и нашёл их недостаточными для моих задач.
ANS>ЗЫ. Ты еще раз обрати внимание на то, что разницы между временем компиляции и временем выполнения в ST нет вообще.
Поздравляю с этим всех поклонников ST. Честно, я очень за всех за вас рад.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>(*) Как я уже сказал, скорее всего у нас есть нестыковка в терминологии. Возможно это метапрограммирование, но это такое же метапрограммирование, как и программирование ячеек в Excel по сравнением с программированием на тех же плюсах. Т.е. несравнимо другой уровень.
Безусловно! Незачем заниматься дрыканьем с АСТ, когда всё можно решить на гораздо более высоком уровне абстракции.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
IT>>(*) Как я уже сказал, скорее всего у нас есть нестыковка в терминологии. Возможно это метапрограммирование, но это такое же метапрограммирование, как и программирование ячеек в Excel по сравнением с программированием на тех же плюсах. Т.е. несравнимо другой уровень.
ANS>Безусловно! Незачем заниматься дрыканьем с АСТ, когда всё можно решить на гораздо более высоком уровне абстракции.
А если нельзя?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Вот я показал, как заменить один метод на другой, добавить/удалить метод. Имхо, это именно метапрограммирование и есть. Только оно осуществляется не манипулированием ни АСТ, ни текстуальным представлением программы, а манипулированием теми сущностями, которые есть результат кодогенерации в других языках. То бишь, если в Nemerle тебе, для создания класса нужно произвести манипуляции с AST, то в ST достаточно сделать `Metaclass new`. Всё, наш новый класс можно использовать в программе.
Добавить новый класс, темболее копированием, проблемы не составляет. Проблема заключается в анализе существующего кода, его декомпозиции, построении нового. Понятно, что любой скрипт может сдалеть фукнцию eval и метода addMethod. Проблема в том, что это очень убогий способ создающий много проблем.
ANS>Добавлю, что в ST нет разницы между write time/compile time/run time. Это важное идеологическое отличие от других систем, где все три этапа четко отличимы. Например, когда я в ИДЕ в ST добавляю класс, то он в самом низу создаётся при помощи того же `Metaclass new`. То есть сама ИДЕ метапрограммирует программу.
Ага. А так же нет реального контроля компилятора и по скорсоти он С никогда конкурировать не будет. Только в бредовом тесте вызова виртуальных методов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Насколько я понимаю строками Потом даём компилеру. Ну или байткод генерить.
И чем это оличается от вызова компилятора во вроемя исполнения?
Понимаешь, ли в чем дело. Основная проблема метапрограммирования не в том, том чтобы скопилировать и выполнить код врантайме. Это практически для любого языка можно сделать. Уж для управляемх вроде Дотнета и Явы точно делается легко. Сделать хотя бы приличную копозцицию кода — это проблема еще та. А уж декомпозиция — это проблемка очень не простая. И решана она на практике только в языках использующих квази-цитирование и сплайсинг (Лисп-ы, МетаОКамл, ТемплейлХаскель). Паттерн-матчин в сочетании с квази-цитированием является вполне удобным средтсвом как композиции, так и декомпозиции.
Вот поглядите на то как можнро сделать печать кода представленного в вдие АСТ: http://nemerle.org/svn/nemerle/trunk/ncc/misc/PrettyPrint.n
Не трудно понять, что аналогичный императивный код был бы практически не читатбельным, а паттерн-матчинг в купе с квази-цитированием делает его почти декларативным.
Если бы еще формирование текста было декларативным, то вообще было бы высший пилота. Причем сделать декларативный вывод текста тоже можно. В АНТЛР сейчас применяется фрэймворк StrigTemplate которая отлично решает эту задачу. Создать ее на макросах более чем ожно и это входит в мои планы. Тогда, например, печать выглядила бы примерно так:
| <[ def $n = $val ]> => %%"def $n = $val;"// $переменная заменяется на значение этой переменной преобразованное в строковый вид.
...
| <[ $obj .[..$args] ]> => %%"$obj.[..$args];"// ..$args раскрывает спиосок разделяя его элементы запятыми
...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Обсуждаемый в этом топике ПМ используется как раз для декомпозиции кода, т.е. для разложения входного потока AST на составляющие и дальшейшего анализа.
Втом то и дело что никак. Не факт, что код можно хотя бы в текстовой форме получить. А если и можно, то дальше труба.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Если так, то практический пример в студию.
Лучший практический пример — сам Немерле. Базовые средства языка нестолько бедны, что вряд ли их было бы достаточно, чтобы писать простой и лаконичный код. Тем не менее макро библиотека расширяет язык до уровня, до которого тому же C# ещё как на четвереньках до Парижу.
Если этого недостаточно, то можно ещё упомянуть компайл-тайм анализ кода, на подобии FxCop. Возможность взаимодействия компилятора с SQL сервером для валидации SQL выражений. Эмуляция или взаимодействие со Spec# для выявления логических ошибок в коде. И т.п. На самом деле, достижимый уровень возможностей макросов Немерле пока ограничены лишь фантазией. А с этим, в силу нашей инертности, у нас у всех проблемы.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, eao197, Вы писали:
E>Сложность функциональных языков я вижу не столько в их синтаксисе или еще каких-то внешних проявлений, сколько в необходимости выдумывания решений в функциональном стиле. Что требует серьезной перестройки сознания. В отличии от императивного подхода. Даже переход от процедурного к объектно-ориентированному стилю не требует такого сдвига в способе мышления.
Ой, не скажи.
Не знаю как там переход на ФП, не пробовал еще серьезно перейти, но вот переход от процедурного к объектному стилю очень сложен. И очень много народу до сих пор не умеют применять ООП...
Тут ведь в чем закавыка. Императивные ООП позволяют делать вид, что ты пишешь ООП, хотя на самом деле программируешь процедурно. Это не так редко встречается. Вроде бы да, человек пишет классы, использует private и public, применяет наследование... А посмотри внимательно — и видно, что это лишь программа в процедурном стиле с очень хорошей поддержкой пространств имен (коими выступают классы). По факту отсутсвует правильное разбиение на объекты, разделение обязанностей, выделение интерфейсов и реальная инкапсуляция. С качественным взаимодействием объектов вообще труба.
Здравствуйте, VladD2, Вы писали:
L>>Насколько я понимаю строками Потом даём компилеру. Ну или байткод генерить.
VD>И чем это оличается от вызова компилятора во вроемя исполнения?
VD>Понимаешь, ли в чем дело. Основная проблема метапрограммирования не в том, том чтобы скопилировать и выполнить код врантайме.
Да я понимаю. Я то всего лишь разницу показывал между С и ST, отвечая на сообщение.
IT>Не совсем. Подобное можно сэмулировать даже в С с помощью указателей на функции.
В ST сделал и тут же работаешь. В Яве так не сделаешь — ты можешь сгенерить класс, подгрузить, начать его использовать, да. Но второй раз без смены класслоадера этого не сделаешь, а это жопа — значит классом надо будет пользоваться как минимум через интерфейс. Хотспот, конечно, чуть чуть выручает, но не совсем, по сравнению с ST там очень много ограничений.
Полагаю, всё упирается в удобство. По мне, так и в ST это тоже делается неудобно
Здравствуйте, IT, Вы писали:
IT>>>А как быть с декомпозицией кода?
L>>Прости, не понял. Что имеется в виду?
IT>Обсуждаемый в этом топике ПМ используется как раз для декомпозиции кода, т.е. для разложения входного потока AST на составляющие и дальшейшего анализа.
В ST конструкции, подобной твоей быть не может. Язык не тот. Я пытаюсь придумать для чего там могут быть макры, кроме как кодогенерилок и не могу придумать. А для кодогенерации вполне хватает и того, что есть — там ПМ не нужен.
Хотя можно ли это тогда называть макросами, я не знаю
Здравствуйте, VladD2, Вы писали:
ANS>>Так это фича языка лиспа такая, что там абсолютно всё реализовано на макросах.
VD>if, car, cdr тоже?
if — в схеме да car/cdr разумеется примитивы.
А если по существу, то цепляться к тому на чём реализовано — это придирки. В чём недостатки реализации ПМ на макрах?
Здравствуйте, IT, Вы писали:
IT>Лучший практический пример — сам Немерле. Базовые средства языка нестолько бедны, что вряд ли их было бы достаточно, чтобы писать простой и лаконичный код.
С Лиспом то же самое, кроме повсеместного использования ПМ.
Здравствуйте, lomeo, Вы писали:
L>if — в схеме да car/cdr разумеется примитивы. L>А если по существу, то цепляться к тому на чём реализовано — это придирки. В чём недостатки реализации ПМ на макрах?
В возможностях. В скорости работы. В ML разбором образцов занимается нехилого размера модуль скомпилированный в нэйтив код и потимизированный по самое нехочу. При этом используются специальные типы данных в которые вставляются "закладки" позволяющие усокрить раоботу. В итоге получается не медленее чем на if-ах в С.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ironwit, Вы писали:
E>>Игроделанье оказалось ужасно неблагодарным занятием
I>можно подробнее осветить причину? очень надо
Платят мало. Ведь море юнцов жаждут стать программистами игр. Уровень у них низкий, но цену они сбивают сильно. Плюс на рынке много конкурентов, что снижает прибыльность.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, ironwit, Вы писали:
E>>>Игроделанье оказалось ужасно неблагодарным занятием
I>>можно подробнее осветить причину? очень надо
VD>Платят мало. Ведь море юнцов жаждут стать программистами игр. Уровень у них низкий, но цену они сбивают сильно. Плюс на рынке много конкурентов, что снижает прибыльность.
Q>Паттерн-матчинг нужен всегда, когда надо извлекать значения из сложных структур данных (более сложных чем int). Хотя бы с той точки зрения, что не надо писать горы if'ов. В том же Лиспе постоянно можно видеть ступенчатые проверки типов и извлечения значений: Q>
. Хотя бы потому что нет foreach и вывода типов. Да и с efficient не всегда получается (т.к. стандартные malloc/new довольно медленные по сравнению с выделением памяти в .NET/Java).
.
?
Если нам не помогут, то мы тоже никого не пощадим.
, но что, разве все программисты после этого сразу сказали: "Вау, как это круто, эй, если кто тут соберется разрабатывать новый язык — имейте в виду, если в нем не будет такой базовой вещи как квази-цитирование, он нафиг никому не будет нужен"? 
Программы с нетривиальной логикой можно писать на любом Тьюринг-полном языке. На C, который прост как табуретка, вон Oracle всякие написаны. 
1.2.0 alpha rev. 655
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Мнение из середины 90-x:
