Компьютерная графика

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Компьютерная графика » Дзен » D - шикарный язык


D - шикарный язык

Сообщений 1 страница 25 из 25

1

Буквально вчера всё-таки нашел время разобраться с этим языком. Нашёл у себя какую-то старую версию GDC (скачать последнюю версию DMD-бандл не могу по причине GPRS-интернета).
Я ещё до этого знал, что он продвигается как замена C++, что даже Андрей Александреску плюнул на C++ и ушёл делать D, что по возможностям и красоте кода этот язык превосходит C++, но боялся, что в этом относительно молодом языке встанет проблема с библиотеками.

Я ошибался!!!

Мало того, что стандартная библиотека Phobos сочетает положительные стороны C++, Delphi, C#, Java, а к тому же и имеет сразу модули для Windows- и Linux-зависимых системных вызовов, но и уже созданные сторонние библиотеки очень впечатляют.

Знакомый Java-программист, которому я начал описывать возможноcти D, резонно спросил насчёт поддержки GUI. Я, ссылаясь на отсутсвие такой поддержки со стороны Phobos, сослался на возможность конвертировать хедеры GTK+ и обращаться к этой библиотеке. Но после этого, на одном из сайтов по D с удивлением обнаружил, что для этого языка уже существуют 4 мощных GUI-библиотеки: DFL, wxD, DWT и GtkD. DFL оказалась пратически копией WinForms из .NET; wxD - обёртка на wxWidgets; DWT - клон Java-библиотеки SWT, на которой написан Eclipse (сходство настолько велико, что разработчики просто ссылаются на Javadocs и прочую документацию к SWT, упоминая лишь некоторые различия в именовании); GtkD - как можно догадаться, обёртка для GTK+. Как говорится, выбирайте по вкусу. Таким образом, об уродских (ну за исключением Qt, хотя тот и использует свои "расширения" C++) GUI-тулкитах для C++, думаю, можно забыть.

Но этого мне было мало, т.к. в первую очередь для меня интересны 3D-приложения. Что интересно, уже существует полноценная обёртка над OpenGL, GLU, SDL, OpenAL, ODE, DevIL и т.п. - Derelict. Причём требует она со стороны программиста только включения и выключения модулей, в остальном работа с этими библиотеками очень похожа на сишную с точностью до различий синтаксиса между C и D, причём в заметно лучшую сторону. Вдобавок язык D предоставляет нам свои богатые объектно-ориентированные и некоторые функциональные возможности без запутанных конструкций C++. Вдобавок и скорость компиляции D-программ намного выше, т.к. компилятору не приходится постоянно перелопачивать гигантские хедеры с нагромождениями #include-директив, а также макросами и запутанными шаблонными конструкциями, т.к. применяется принцип модульности. Имхо скорость компиляции (к сожалению не замерял) должна сравниваться со скоростью компиляции Delphi и Java.

У меня даже появилась идея бросить к чертям этот инопланетный C++, в котором оптимизация зависит от каждой лишней строчки const, virtual или inline (в D данные оптимизации применяются автоматически исходя из опций компиляции), а постоянные невидимые преобразования типов (коих к каждому типу C++ может применить кучу, причём по цепочке и плевать он хотел на то, что думал программист - лишь бы скомпилировалось), якобы призванные упростить код, на самом деле придают больше головной боли из-за малоявных эффектов. Интересно, что низкоуровневость при этом никуда не исчезла, убрали только всё лишнее (например оператор -> заменили на точку - компилятор всё-таки не настолько тупой, чтобы не понять когда ему предлагают SomeClass, а когда SomeClass*). Шаблоны переделали, сделали их, как мне показалось, более чёткими, добавили микшины вместо множественного наследования - имхо к лучшему.

Да, рантайм-возможностей Java, C# или Objective-C у языка D нет... Думается, что этот недостаток всё-таки был обоснован... Тем более, что D может выполняться и интерпретатором DMDScript. Причём скрипты эти получаются достаточно низкоуровневые.

Спасибо за внимание.

0

2

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

Код:
// A.h

class A {
public:
    template <typename T> void a ( T value );
};

// A.сpp

template <typename>
void A::a (T value) {}

Потому что,  если я затем хочу проэкспортировать функцию "а" вызывом из либы А::а ( 0.5f ), то линкер материться, что такой функции он, дескать, не видит!
Тут мне товарищ по работе объясняет, что мол, давно известно, что тело такой функции нужно описывать в хедере. Опа!
А почему ж тогда, если я делаю ту же самую вещь, но функцию вызываю только из какой-либо другого члена класса в модуле A.cpp линкер все радостно скушает!
В чем проблема ему проэкспортировать специализацию функции A::a<float> (0.5f), чтобы видеть ее? АГХР, не понимаю этого!

ПС:
1. Я и так очень редко использую шаблоны - а тут эта пакость вовсе отбила желание ими пользоваться!
2. Недавно обнаружил, что по СТАНДАРТУ С++ параметр float для template-объявления НЕ ПРИМЕНИМО! (C2993)

Код:
// If it is a function template, use a function argument to pass in the floating point non-type template parameter
// (this code will be valid in the Visual Studio .NET 2003 and Visual Studio .NET versions of Visual C++). If it is a class template, there is no easy workaround.

// C2993b.cpp
// compile with: /c
template<class T, float f> void func(T) {}   // C2993

// OK
template<class T>   void func2(T, float) {}

Что же это твориться, господа! То есть это действительно логично (я сам использовал бы второй способ, даже не зная о стандарте), но о чем думали
разработчики языка и комитет по стандартизации до этого?!

Отредактировано stea1th (2008-08-08 12:13:49)

0

3

Я конечно не ярый сторонник С++, но по-моему практически всему есть объяснение. Во первых язык этот довольно древний, но например С# и Net тоже неоднозначны. Ну а по поводу шаблонов, это же улучшенные макросы, а какой файл реализации у макросов? Но тем не менее можно сделать несколько файлов реализации одного объявления , только нужно не забыть и его заинклюдить.

0

4

Я конечно не ярый сторонник С++, но по-моему практически всему есть объяснение. Во первых язык этот довольно древний, но например С# и Net тоже неоднозначны. Ну а по поводу шаблонов, это же улучшенные макросы, а какой файл реализации у макросов? Но тем не менее можно сделать несколько файлов реализации одного объявления , только нужно не забыть и его заинклюдить.

Это все понятно, но, согласись, плохо! Пример шаблонов - просто еще один повод поговорить об неоднозначности и, скажем, некорректности "стандартов". (В том же примере, я обошел проблему, просто заключив вызов шаблонной функций в экспортируемую НЕшаблонную функцию. Тело же шаблонной функции осталось в цпп-файле. То есть чуть колдовства - и стандарт вроде как и не стандарт уже. Хотя можно попенять и на непонятливость компилятора, или же мою собственную :)).
Что же до того, что в других языках - свои проблемы - кто спорит?! Более того, я уважаю С++ и когда мне говорят, к примеру: "переходи на JAVA, С++ - говно", я спокойно отвечаю, что мне лень, не вступая в бесполезный, хотя и не беспочвенный, спор )). С++ довольно хороший и мощный язык. При его грамотном использовании и при отсутствии параноидального желания "применить ВСЕ ВОЗМОЖНОСТИ языка" программирование на нем даже доставляет удовольствие. Другое дело, что иногда встречаются моменты (как вышеизложенный, например), когда хочеться напинать Страуструпу за его придумку и всем тем, кто ее попытался "развить".
В итоге я и не за, и не против языка, я лишь выразил свое недовольство и обозначил надежду на появление более развитого и приятного инструмента программирования.

0

5

А зачем - template<float f>?. Этого я не понимаю.

1. Я и так очень редко использую шаблоны - а тут эта пакость вовсе отбила желание ими пользоваться!

Не понимаю почему пакость, вроде наоборот правильно. Есть extern, но по-моему это как раз и пакость.

0

6

Booster:
А зачем - template<float f>?. Этого я не понимаю.

stea1th:
То есть это действительно логично (я сам использовал бы второй способ, даже не зная о стандарте), но о чем думали
разработчики языка и комитет по стандартизации до этого?!

Booster:
Не понимаю почему пакость, вроде наоборот правильно. Есть extern, но по-моему это как раз и пакость.

stea1th:
Потому что,  если я затем хочу проэкспортировать функцию "а" вызывом из либы А::а ( 0.5f ), то линкер материться, что такой функции он, дескать, не видит!
Тут мне товарищ по работе объясняет, что мол, давно известно, что тело такой функции нужно описывать в хедере. Опа!
А почему ж тогда, если я делаю ту же самую вещь, но функцию вызываю только из какой-либо другого члена класса в модуле A.cpp линкер все радостно скушает!
В чем проблема ему проэкспортировать специализацию функции A::a<float> (0.5f), чтобы видеть ее? АГХР, не понимаю этого!

Пакость - не шаблон, а проблемы с ними! (Читай пост внимательней :))

0

7

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

Код:
// "ForTemplateFunctionsInst.h"

template void Function <float> ( float value );
...
// уже надоело ? не расслабляйся!
...
template void Function <aghr> ( argh value );
...
// ну давай, еще немного
...

Ухх! Но сколько же еб** с этим, ты представляешь? И все потому что шаблону функции или класса запрещено разделять объявление и определение. Решение типа "#include "TemplateFunctions.cpp"" - по большому счету, хак, и, по меньшей мере, не приветствуется ))
Хорошо сказано в статье Лаптева В. "Шаблоны и модули":

Таким образом, явное воплощение обеспечивает как раз такую организацию файлов с шаблонами, которую мы хотели иметь с самого начала. Однако этот способ тоже не свободен от недостатков. Как пишут Джосаттис и Вандевурд [1], программист должен тщательно следить за тем, какой тип шаблона воплощается. Для больших проектов это быстро становится слишком обременительным, поэтому они не советуют применять этот метод в промышленных проектах.

Я не против шаблонов,  но против вот таких вот проблем.

0

8

Честно говоря не понимаю этих проблем. Просто нужно понять, что шаблон это не функция и не класс. Шаблон это улучшенный макрос, и функционирует подобным образом. То есть вначале генерятся конкретные функции и классы для конкретных типов, а уже потом это становится нормальными функами и классами. И для их генерации компилятор обязан видеть реализацию. Так что тут видимо проблемы с непониманием работы шаблонов. А выносить реализацию в cpp можно, и включать её нужно, это как я уже писал одна из фич шаблонов, множественная реализация. С++ сложен, но не надо сразу огульно обвинять разрабов в бездарности, во всём может быть более глубокий смысл. Кстати многие его проблемы в том что он так и остался языком сугубо стадии компиляции, но на самом деле в этом тоже есть свои плюсы, хотя бы высочайшая эффективность. Интересно когда выйдет первая игра на C# уровня топовых?

0

9

Так что тут видимо проблемы с непониманием работы шаблонов.

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

Честно говоря не понимаю этих проблем.Просто нужно понять, что шаблон это не функция и не класс. Шаблон это улучшенный макрос, и функционирует подобным образом. То есть вначале генерятся конкретные функции и классы для конкретных типов, а уже потом это становится нормальными функами и классами. И для их генерации компилятор обязан видеть реализацию.А выносить реализацию в cpp можно, и включать её нужно, это как я уже писал одна из фич шаблонов, множественная реализация.

Но то, что шаблон - продвинутый макрос, совсем не означает, что приемы работы с другими средствами языка тут уже гмм.. не применимы. То есть тут не нужно изобретать велосипед, чтобы понять, что раз я везде работаю по цепочке cpp-caller -> h-definition -> cpp-implementation, то и с шаблонами мои действия не должны быть иными! Так что проблем никаких.. просто в очередной раз убеждаюсь, что шаблон на С++ реализован кривовато.

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

Опять пост был невнимательно прочтен (видимо привычка быстро читать сказывается :)) Повторюсь: "но о чем думали
разработчики языка и комитет по стандартизации до этого?!" Где же тут слово "бездарность" ? Вроде нет нигде... Все просто: разработчики не бездарны, просто, видимо не могут прийти к определенным (вполне очевидным и простым) решениям из-за каких-то внутренних проблем в процессе своей работы. А глубокий смысл может быть и в восклицании "упс!", когда работаешь с шаблонами :)

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

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

Интересно когда выйдет первая игра на C# уровня топовых?

О, очень скоро! Хотя, может быть, и не шарпе, но на любом другом ВМ-языке. Хочу так же заметить, что все игры на мобильных платформах (за исключением КПК) написаны на яве и ее разновидностях. И, как ты понимаешь, времени, которое осталось до того, чтобы эти платформы оторвали себе хороший кусок в мире игрового бизнеса и, тем самым, привлекли внимание топовых тайтлов, осталось совсем немного.

0

10

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

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

На С# я писал около года, и честно скажу большого удовольствия несмотря на все его штучки не получил. Хотя если-бы не GC, может у меня и было-бы более приятное впечатление.

0

11

Как это происходит - я уже и сам понял )) Не зря давал ссылку на статью Лаптева.

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

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

Зачем это делается для классов и функций понятно, а вот зачем это делать для шаблонов совсем не понятно. Про одинаковые приёмы здесь речи нет и быть не может.

Сомнительное утверждение. Разные способы делать в принципе одинаковые действия приводят к неразберихе (как в моем случае) и неоднозначности.

Но всё же про игры уровня именно топовых на С# и явах по-моему думать пока рановато. На мобильных платформах совсем не топовые игры.

Насчет рановато - не знаю: Кармак вроде так не думает. А то, что игры на мобильных платформах "совсем не топовые" - опять-таки сомнительно! Топовые по какому критерию: качество графики, сюжета, денежных вложений или компаний-разработчиков. Мобильные Splinter Cell, Prince of Persia, NFS и тп то есть "совсем не топовые" ?. Или скажем так: иксбокс вышел 2-3 года назад, ви и пс3 1.5-2. Соотвественно, графика и их возможности уже не сравнимы с топовыми решениями на базе ПК. То есть и там уже нет хай-енд продуктов? По какому признаку ты определяешь "топовость" ?

0

12

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

Because D has a true module system, rather than textual #include files, there are only template definitions in D. The need for template declarations and export is irrelevant.

в Template Declaration, Defenition, and Export

0

13

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

На стадии компиляции собирается конкретный модуль, и что твориться в других ему совершенно до лампочки. На этапе линковки происходит связывание внешних вызовов. Компилятору нужно видеть только объявление функции, и он этот вызов спокойно скомпилит. Дело линковщика связать между межмодульные вызовы. Шаблоны целиком обрабатывает компилятор, и повторю когда он видит создание объекта по шаблону он обязан уже всё знать о реализации этого шалона.
Ну я же говорю export уже в вошло стандарт, и VC 2005 его понимает, хотя это по-моему и не принципиально, можно просто везде включать cpp и спокойно жить. Понять про одинаковые приёмы я не могу, просто потому-что так хочется, это несколько странно звучит. Разнести то их не проблема, просто нужно сделать так чтобы компилятор это увидел, и всё.

Ну не знаю я яву и её возможностей, но знаю что там тоже автоматизированное управление памятью, но может там это и нормально сделано, без понятия. А что Кармак будет делать Doom4 на ява или С#? И что на PS3 ява?

0

14

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

А что Кармак будет делать Doom4 на ява или С#? И что на PS3 ява?

Знал, что ты это скажешь. В очередной раз убеждаюсь, что ты либо невнимательно читаешь посты, либо не понимаешь их до конца. Разве я сказал, что на ПС3 ВМ-язык? Процитируй, если не трудно..
Речь шла о том, что ты не конкретизировал понятие "топовый". На примере сравнения возможностей ПС3 и ПК я показал, что если "топовый" проект определять по критерию качества графики, то твое мнение насчет мобильных платформ ошибочно! Ведь консоли УЖЕ проигрывают по производительности ПК в плане обработки графики, но хай-енд продуктов там - как грязи. Та же ситуация и со смартфонами, мобильниками или чем-нибудь еще. Там тоже ЕСТЬ топовые игры на ВМ-языке.
И вот увидишь, ДУМ4 выйдет на каком-нибудь симбиане параллельно с ПК/ПС3/ИКСБОКС-платформами в ближайшем будущем. И, по твоему мнению, это не будет топовым продуктом?! Если нет - то дальше обсуждать это бесполезно.

0

15

Вроде приставки это портативные, а не мобильные платформы. И речь собственно не о них, а о ВМ с автоматическим управлением ресурсами. Я имел ввиду, что подходы таких ВM языков не очень-то вяжутся с одним из самых сложных и ресурсоёмких направлений - играми, где контроль над ресурсами наиважнейшая вешь. Ну например возможно чтобы тот же дум был написан на ява? Под топовыми я имею ввиду прежде всего последние по передовым технологиям проекты, такие как farcry, crysis и т.д. Вроде не понял о чём речь как раз не я.

0

16

stea1th
Да ты можешь попробовать сам написать мощное 3д-приложение на C# или Java хоть сейчас.
Сравнивать J2ME (Java для мобильников) и J2SE (настольная Java) - НЕ СЛЕДУЕТ. J2ME построена как тонкая обёртка над нативными функциями платформы, реализованными на C/C++, плюс имеет особенности в функционировании JVM, а J2SE - чрезвычайно сложная и тяжелая система. Аналогично и .NET.

Я потихоньку начал разбираться с D, собрал последний компилятор GDC (DMD 1.020), попробовал некоторые библиотеки, в частности Derelict - обёртку для OpenGL, GLU, SDL, FreeType, OGG, ODE, DevIL, OpenAL - очень неплохо. Попробую сделать на её базе что-нибудь.
Шаблоны, кстати, реализованы несколько хитрее, нежели в C++. Так, например, они не привязываются к функции или классу, а могут работать как контейнеры для них. А в D 2.0 Александреску вообще на базе шаблонов целый функциональный язык соорудил. Причем шаблоны могут иметь произвольное число аргументов, чем, собственно, Александреску и пользуется. Т.о. в D шаблоны позволяют реально метапрограммировать без особых проблем.

0

17

Вроде приставки это портативные, а не мобильные платформы. И речь собственно не о них, а о ВМ с автоматическим управлением ресурсами. Я имел ввиду, что подходы таких ВM языков не очень-то вяжутся с одним из самых сложных и ресурсоёмких направлений - играми, где контроль над ресурсами наиважнейшая вешь. Ну например возможно чтобы тот же дум был написан на ява? Под топовыми я имею ввиду прежде всего последние по передовым технологиям проекты, такие как farcry, crysis и т.д. Вроде не понял о чём речь как раз не я.

Вот прицепился-то к приставкам... Разве я говорил, что приставки - мобильные платформы ?! Ощущение - будто мы на разных языках разговариваем! Еще раз повторю: пример с приставками привязан не к использованию ВМ-языков, а для определения "топовости" продукта!!! Однобокое определение "топовый - самый технологичный" не является для меня полным определением этого понятия. Разговор об этом, я думаю, следует закончить, так как разжевывать тебе дальше то, что я писал уже в 2х постах - бесполезно (даже обидно, ведь вроде ясно изъясняюсь)...
Контроль над ресурсами компьютера - действительно не прерогатива ВМ-языков. С этим я согласен... тем не менее, дум уже сечас (естественно, при грамотном подходе) может быть реализован на технологии той же самой ява. С трудностями, как же без них, но благо мощности позволяют. Так что, это вопрос только желания и времени. К тому же, ВМ-языки не стоят на месте и постоянно совершенствуются.
Еще один пример, если позволите: ось для Мака написана на объектном С. Там, вроде как, нет виртуальной машины. Зато там есть такой механизм как посылка сообщений (или что-то вроде этого). Как и в случае с виртуальной машиной, здесь тоже существует контроль над подобными операциями: например, можно послать сообщение нул-объекту и все будет ок (в локальном смысле). Таким образом, там присутствует "следящий механизм" (+нормальная рантайм работа с метаинформацией, которая в С++ сделана в виде убогого РТТИ), что налагает свое пенальти на все действия (в первую очередь, скорость выполнения программы). То есть, на самом деле, все признаки ВМ-языков. И что, по-твоему, Леопард - плохая ось? Хуже чем сипипишная винда ? Гм... сомневаюсь. При разных начальных данных (скорость работы С++-кода выше скорости работы ObjC-кода), программисты яблока сумели сделать высокопроизводительный продукт, работавший и работающий на довольно слабом железе. Или ты поспоришь? Или захочешь попенять на то, что ОбжективС может использовать напрямую С-библиотеки со всеми вытекающими последствиями? Или опять прицепишься, что ObjC - не С-шарп, не ява, не питон и тп и вообще не ВМ-язык и что пример - дурной, и я вообще ничего не понимаю :)?

Да ты можешь попробовать сам написать мощное 3д-приложение на C# или Java хоть сейчас.
Сравнивать J2ME (Java для мобильников) и J2SE (настольная Java) - НЕ СЛЕДУЕТ. J2ME построена как тонкая обёртка над нативными функциями платформы, реализованными на C/C++, плюс имеет особенности в функционировании JVM, а J2SE - чрезвычайно сложная и тяжелая система. Аналогично и .NET.

Написать - работа не позволяет, хотелось бы проводить поменьше времени в обнимку с компом. К тому же у меня нет (вообще) навыков работы с ВМ-языками (кроме, разве, луа). Так что специалистом по ним я себя назвать не могу.
Языки сравнивать и не пытался, так как знал только то, что они существуют в двух вариантах. На счет различий в языках МЕ и SE - вот так сказал мой друг, работающий профессионально на Яве (и имеющий опыт работы с МЕ): "в симбиане - виртуальная машина может работать на уровне оси и быть написана на си++, а в обычных телефонах она может быть написана на их собственных языках программирования (хоть на ассемблере). при этом приложение в любом случае запускается под виртуальной машиной. А виртуальная машина - есть прослойка между нативными вызовами оси и интерфейсом программирования". Так что уж прости, доверюсь ему, так как знаю лично его самого и его способности и знания, в отличие от твоих.
Тем не менее, история про ось Мака, я думаю, будет достаточна для того, чтобы убедиться, что написать хорошее (красивое, если уж так воспринимать "топовость") приложение возможно и на языке, имеющим собственный механизм "самоконтроля"... Если нет - продолжать диспут достаточно проблематично и бессмысленно.
ПС:
А шаблоны в ДИ вроде как, действительно, круты!

Отредактировано stea1th (2008-08-11 21:34:09)

0

18

stea1th написал(а):

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

Извини, конечно, но и SE-машину можно написать на любом языке программирования.
Я имел в виду стандартную библиотеку классов. Для J2ME практически все методы важнейших классов являются native (например, класс Graphics). В J2SE многие классы вообще являются абстрактными и, таким образом, тянут за собой цепочку виртуальных классов. Это архитектурное решение. Отчасти, J2SE потому и работает не очень шустро.

Кстати, на D существует проект DWT - портированная с Java библиотека интерфейса SWT ( на которой написана известная платформа/IDE Eclipse). А на основе DWT разрабатывается IDE Poseidon. Внешне выглядит она как типичная среда на платформе Eclipse, но по ощущениям работает все-таки быстрее.

Мне, тем не менее не кажется, что разработчики игровых проектов класса AAA перейдут с проверенного и хорошо им известного языка C++ на .NET, Java или тот же D. С другой стороны, в аких проектах вполне возможно написание утилит, редакторов и прочих инструментов разработки на .NET, это практикуется уже сейчас.

0

19

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

Вот прицепился-то к приставкам... Разве я говорил, что приставки - мобильные платформы ?! Ощущение - будто мы на разных языках разговариваем!

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

Повторюсь я ничего не имею против ВM. Net например вообще с натяжкой можно таковым назвать, так как при загрузке net код компилиться в нативный. Очень большой вопрос там именно с автоматическим сборщиком мусора,  известно что он работает быстрее чем С++ хип, но только с оговоркой что памяти бесконечно. На практике бесконечная память это как говориться из области фантастики. И получается что память забирается но не освобождается, и повлиять на это к сожалению практически не возможно, и это называется GC по последнему слову техники. У меня были такие проблемы, и борол я их очень долго. Так что извини но терады по поводу леопарда и пр. были в пустую, ведь я уже писал ранее -

Ну я вообщем-то и не спорю, что в какой-то степени это уже устарело ибо мощности сейчас очень неслабые.

.

Однобокое определение "топовый - самый технологичный" не является для меня полным определением этого понятия.

Далось тебе это определение, я этим вобщем-то имел просто хорошо жрущее ресурсы приложение.

И что, по-твоему, Леопард - плохая ось?

Логическая цепочка конечно впечатлила впечатлила, но так и не понял почему я так вдруг думаю. Вся штука в том что подобные вещи как системы сообщений, не являются ботлнеком OC. Ботлнек например это переход в режим ядра, который затрачивает тысячи тактов. Но и всё равно это не показатель при современных мощностях в работе ОС, занимающихся открытием окошек, вот если был-бы 286 тогда другой табак.

0

20

Извини, конечно, но и SE-машину можно написать на любом языке программирования.
Я имел в виду стандартную библиотеку классов. Для J2ME практически все методы важнейших классов являются native (например, класс Graphics). В J2SE многие классы вообще являются абстрактными и, таким образом, тянут за собой цепочку виртуальных классов. Это архитектурное решение. Отчасти, J2SE потому и работает не очень шустро.

Ты на самом деле подтвердил то, что сказал мой друг и то, что сказал я, когда говорил о "топовых" играх на мобильных платформах. Не больше, не меньше. Твои тезисы не отменяют то, что МЕ работает с виртуальной машиной - то есть является языком, скорость выполнения кода которого существенно меньше С++.  Вот и все )) Ты просто говоришь, что сразу за вызовом яваМЕ-интерфейса идет вызов натив-нтерфейса - да ради Бога! Пожалуйста. Я удивлюсь, если в SE цепочка переходов не приведет к натив-вызову? Или создатели SE - боги - сумели изобрести универсальный язык, ВООБЩЕ не вызывающий методов, родных для данной платформы? А то, что там все более громоздко, чем в МЕ сразу отменяет, что последний построен на базе ВМ?
В итоге пришли к тому, с чего начали... Виртуальная машина на мобильной платформе есть? Есть! Высококлассные, раскрученные бренды есть? Есть! Значит можно написать топовую (по множеству критериев, а не только по качеству графики) игру на платформе ВМ-языка? Гм.. ну, значит, можно (((

Мне, тем не менее не кажется, что разработчики игровых проектов класса AAA перейдут с проверенного и хорошо им известного языка C++ на .NET, Java или тот же D. С другой стороны, в аких проектах вполне возможно написание утилит, редакторов и прочих инструментов разработки на .NET, это практикуется уже сейчас.

Как говориться: "когда кажеться - креститься надо" )) Мир на шарпе, нете или ди клином не сошелся...

0

21

В общем-то ты уже совсем согласился хоть и не выразил это явно

Гм.. с чем ?

А чего ты хотел доказать приводя в пример PS3, XBox и пр. так и не понял.

Это уже я понял, что ты ничего не понял и не поймешь в этом примере.. собственно, и не надо уже - надоело (уже ведь три раза разжевал).

Повторюсь я ничего не имею против ВM

Я тоже. И более того, тебя посвящать в этот культ и не собирался.

Логическая цепочка конечно впечатлила впечатлила, но так и не понял почему я так вдруг думаю.

Я не сказал, что ты так думаешь. Ты разве не знаком с таким стилем написания текста, когда автор пытается предугадать мысли читающего? Есть тезис, и у читающего обязательно возникает либо положительная, либо отрицательная, либо нейтральная оценка. В среднем на все мои предложения ты давал отрицательную оценку. Как ты думаешь, каково было мое "предугадывание" ? (на всякий пожарный - это риторический вопрос)

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

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

"Интересно когда выйдет первая игра на C# уровня топовых?"

а ты все в частности впадаешь.. Тяжко. Говорю ж - разговариваем на разных языках. Тут уж ничего не поделать. В итоге мы перешли как раз в разговор по типу "мой язык лучше ...". Эх, грустно..

0

22

stea1th написал(а):

Мир на шарпе, нете или ди клином не сошелся...

ну а что например?

Ну ладно, а то холивар уже какой-то получается...

0

23

ну а что например?

Та же Луа, Питон ... шутка! Я имел ввиду, что мысль у разработчиков языков не стоит на месте и они что-нибудь да придумают ))
А насчет "священной войны" - согласен. Мне тоже вся эта тягомотина порядком надоела. Так что если кого обидел - извиняйте. Как говориться: "давай, пока!"

0

24

$tatic, ничего так пиарчик )
На прошлом форуме задавал вопрос Борескову про мнение о Ди, на этом уже увидел в числе обсуждаемых языков, тоже запостил немного: DigitalMars D и OpenGL

2All
А вы чего в дзене с Ди отжигаете? Или Ди был добавлен в список языков с вашей подачи здесь?..

0

25

digited
Сначала был пост в Дзене, а затем уже в раздел о языках был добавлен пункт "D".

0


Вы здесь » Компьютерная графика » Дзен » D - шикарный язык


создать свой форум бесплатно