Информация об изменениях

Сообщение Re[6]: Область применения С++ от 07.07.2017 23:57

Изменено 08.07.2017 0:05 Mystic Artifact

Re[6]: Область применения С++
Здравствуйте, WolfHound, Вы писали:

VD>>>Ее выгоднее делать на видеокартах. И как не странно есть не мало решений на высокоуровневых языках для этого.

MA>> Нормального доступа из высокоуровневых языков к технологиям общения с картами как не было так и не ожидается. Поэтому проще взять C++.
WH>Где лучше доступ ещё вопрос.
WH>http://rsdn.org/forum/nemerle/4220330.flat
Автор: Denom
Дата: 04.04.11

Не совсем ясно на что именно ты дал ссылку (что конкретно имел ввиду). Сорри.
С учётом того что всё появляется в первую очередь в виде C/C++ хидеров...я полагал это не будет даже смысла обсуждать.
Смотри:
Я думаю, что язык X просто должен уметь инклюдить хотя бы C хидеры (и иметь достаточно гибкую систему типов что-бы обслужить их). Ты никогда не заставишь выпускать windows sdk или linux-headers в другом виде. Более узкие вещи — тем более.
Возможность использовать и просто брать и использовать это достижимые цели с ценой работы отличающейся на порядки (в одном из случаев — просто ничего не надо делать дополнительно).
Если речь про Nemerle и .NET в частности, то прости, managed->native transition и обратно имеет весьма не нулевую цену. В итоге народ делает calli в нативный код без этого, но это годится далеко не везде.

Если я мимо, объясни в кратце и конкретно плиз.

ADD: Привет полуношникам!
Re[6]: Область применения С++
Здравствуйте, WolfHound, Вы писали:

VD>>>Ее выгоднее делать на видеокартах. И как не странно есть не мало решений на высокоуровневых языках для этого.

MA>> Нормального доступа из высокоуровневых языков к технологиям общения с картами как не было так и не ожидается. Поэтому проще взять C++.
WH>Где лучше доступ ещё вопрос.
WH>http://rsdn.org/forum/nemerle/4220330.flat
Автор: Denom
Дата: 04.04.11

Не совсем ясно на что именно ты дал ссылку (что конкретно имел ввиду). Сорри.
С учётом того что всё появляется в первую очередь в виде C/C++ хидеров...я полагал это не будет даже смысла обсуждать.
Смотри:
Я думаю, что язык X просто должен уметь инклюдить хотя бы C хидеры (и иметь достаточно гибкую систему типов что-бы обслужить их). Ты никогда не заставишь выпускать windows sdk или linux-headers в другом виде. Более узкие вещи — тем более.
Возможность использовать и просто брать и использовать это достижимые цели с ценой работы отличающейся на порядки (в одном из случаев — просто ничего не надо делать дополнительно).
Если речь про Nemerle и .NET в частности, то прости, managed->native transition и обратно имеет весьма не нулевую цену. В итоге народ делает calli в нативный код без этого, но это годится далеко не везде.

Если я мимо, объясни в кратце и конкретно плиз.

ADD: Привет полуношникам!

UPD: Ссылка на статью у меня не вызывает никакого вау. Я читал нечто подобное буржуйское. В обоих случаях пока это далековато от практики, хотя я абсолютно согласен, что спец языки могут дать нечто интересное для обработки графики. Какой-то есть и так и не в виде статьи. Но, это совершенно ортогонально к топику: если мы хотим иметь отзывчивую графику — мы обязаны избавится от всех лишних расходов, особенно — если разработчик разрабатывает не middleware, а настоящий frontend в виде библиотеки или приложения.