Что люди используют JScript. Сеть для?
, Каковы преимущества наличия непрерывного блока памяти? А именно, почему у меня должен был бы быть непрерывный физический блок памяти в системном вызове? Есть ли какая-либо причина, я не мог просто использовать vmalloc?
От Google "я Чувствую себя Удачливым" на vmalloc:
kmalloc является предпочтительным путем, пока Вам не нужны очень большие площади. Проблема, если Вы захотите сделать DMA из/в некоторое устройство, необходимо будет использовать kmalloc, и Вам, вероятно, будет нужен больший блок. Решение состоит в том, чтобы выделить память как можно скорее, прежде чем память будет фрагментирована.
10 ответов
Роб - Я в гневе использовал JScript.NET в одном месте своего кода, который, по сути, предназначен для раскрытия функциональности его метода eval. Вот урезанная версия:
static public class Evaluator
{
private const string _jscriptSource =
@"package Evaluator
{
class Evaluator
{
public function Eval(expr : String) : String
{
return eval(expr);
}
}
}";
static private object _evaluator;
static private Type _evaluatorType;
static Evaluator()
{
InstantiateInternalEvaluator();
}
static private void InstantiateInternalEvaluator()
{
JScriptCodeProvider compiler = new JScriptCodeProvider();
CompilerParameters parameters;
parameters = new CompilerParameters();
parameters.GenerateInMemory = true;
CompilerResults results;
results = compiler.CompileAssemblyFromSource(parameters, _jscriptSource);
Assembly assembly = results.CompiledAssembly;
_evaluatorType = assembly.GetType("Evaluator.Evaluator");
_evaluator = Activator.CreateInstance(_evaluatorType);
}
static public object EvaluateToObject(string statement)
{
try
{
return _evaluatorType.InvokeMember(
"Eval",
BindingFlags.InvokeMethod,
null,
_evaluator,
new object[] {statement}
);
}
catch (Exception)
{
InstantiateInternalEvaluator();
return null;
}
}
Очевидно, вы можете создавать перегрузки для других возвращаемых типов. Я не могу утверждать, что первоначальная идея была моей! Это можно использовать, например, для оценки строкового выражения типа 3 + 4 до 7 без синтаксического анализа выражения.
JScript .NET - это современный язык сценариев с широким спектром приложений. Это настоящий объектно-ориентированный язык, и все же он по-прежнему сохраняет ощущение "скриптинга" . JScript .NET поддерживает полную обратную совместимость с предыдущими версиями JScript, в то же время включая отличные новые функции и предоставляя доступ к общеязыковой среде выполнения и .NET Framework (из JScript.NET ).
Кроме того, вы можете Считайте этот пост stackoverflow полезным: Можно ли использовать JScript.NET для создания сценария приложения .NET?
Что касается того, кто использует, я, честно говоря, не знаю (я почти уверен, что они есть).
Прочтите Введение JScript.NET .
Лично я думал, что это может быть неприятно для веб-разработчиков, которые привыкли писать на простом JScript и хотят получить преимущества .NET без необходимости изучать новый язык или для тем, кто хочет, чтобы весь их код был написан на одном языке.
Страница JScript.NET в Википедии довольно поясняющая: http://en.wikipedia.org/wiki/JScript_.NET
Короче говоря, это похоже на JavaScript с библиотека .NET.
Я не знаю, как он сравнивается с точки зрения производительности, но я знаю, что JScript.NET - один из языков, которые вы можете использовать с Unity 3D .
Я просто предположил, что он использовался Microsoft для увеличения количества языков, поддерживаемых .NET при запуске, в маркетинговых целях.
JScript .NET - один из языков, поддерживаемых для написания расширений приложений для семейства продуктов Sony для редактирования мультимедиа. Sound Forge & Vegas.
В частности, в Sound Forge есть окно, которое можно использовать для редактирования и запуска сценариев для работы со звуковыми файлами.
Оказалось, что компания Microsoft довольно легко добавила скрипты в ваше приложение, используя один (или все) из языков, поддерживаемых .NET. VB, JScript и C#. Достаточно просто выставить некоторые объекты из Вашего приложения и передать эти объекты (собственно сборки) компилятору вместе с текстом пользовательского скрипта.
У них есть веб-форум для сценаристов Sound Forge
С помощью инструмента управления бизнес-процессами Metastorm BPM можно использовать JScript.Net для расширения рабочих процессов. Например, вы можете добавить пользовательские .Net .dlls в движок и взаимодействовать с ними в ваших процессах, используя JScript.Net.
Мой опыт был весьма положительным. Я реализовал всего несколько небольших скриптов, но я бы предпочел скриптинг с помощью JScript.Net, а не VBScript (второй поддерживаемый язык сценариев) в любое время.
.Я опаздываю на вечеринку, но хочу добавить свое мнение:
Я вижу, что JScript.NET полезен для кода на стороне сервера . Вполне естественно использовать что-то на стороне сервера, по сути то же самое, что и на стороне клиента. Кроме того, это значительно упрощает работу с JSON, поэтому может быть полезным, если вы создаете веб-службу, которая обменивается данными через JSON.
Я написал веб-службу, где работаю на C #, но думаю о переходе на JScript.NET по этим причинам.
Я использую его довольно часто, почти исключительно для ASP.NET и связанных с ним веб-вещей.
Вы можете использовать его практически для всех вещей, для которых вы можете использовать другие языки .NET.Он делает MSIL таким же, как и другие;) Скомпилированный с опцией "fast", которая включает некоторые собственные свойства javascript, такие как расширения прототипов и eval, он работает так же, как и любой другой код в CLR.
Это, конечно, не полноценный член семейства, в том смысле, что он кажется несколько отставшим в .NET 1.1 с точки зрения функций, поддержки инструментов не существует, а документация просто потрясающая. Это одна из причин, почему мне это так нравится, на самом деле, это заставляет меня чувствовать, что я программирую.
Если у вас есть много (j) скриптов, которые нужно преобразовать в .NET, это очевидный выбор, так как обычно вам потребуется совсем немного переписывать, чтобы это работало. В противном случае нет особых причин для выбора JScript.NET перед любым другим языком .NET, и есть много причин не делать этого.
Все сводится к личным предпочтениям, поскольку все заканчивается одним и тем же кодом CLR, независимо от языка. Я считаю JScript.NET простым в использовании, естественным для написания и гибкой простотой, как никакой другой язык, который я пробовал, поэтому я использую его, пока не столкнусь с проблемой, с которой язык просто не может справиться. Еще не произошло.
Ну, я пытаюсь использовать его. Не могу сказать, что у меня получилось.
Я не делал много веб-кодирования в любой среде, но вот мои 2 цента.
Я хотел вывести некоторые таблицы базы данных на веб-страницу, поэтому я создал быструю страницу Classic ASP (да, да, я знаю), которая извлекала данные из SQL Server и возвращала таблицу в виде объекта JSON. Вместо того чтобы искать сериализатор JSON для VBScript, я просто написал обе стороны на J(ava)script и импортировал json2.js на сервер для обеспечения сериализации. Это отлично работает; честно говоря, потребовалось меньше часа, чтобы заставить его выплюнуть обратно хорошее JSON-представление таблицы, 50 минут из которых были бесплодными попытками заставить JScript импортировать json2.min.js напрямую, а не бросать <% %> обертки вокруг него и переименовывать его в json2.min.asp.
Но все говорят, что использовать классический ASP в наше время - это плохо и неправильно, поэтому я пытаюсь заменить мою быструю и грязную реализацию ASP + Jscript + ADO на ASP.NET + Jscript.NET + ADO.NET. После некоторых моментов, когда я бил головой по клавиатуре, я установил ASP.NET v4.0.30319 на IIS6 и создал страницу "hello, world", которая выполняет несколько простых циклов javascript через директиву <@ language = "JScript">. Пока все хорошо.
Если бы я следовал лучшим практикам, я бы обернул все в класс и т.д., но поскольку я просто пытаюсь выбраться из подъезда, я попробовал сделать быстрый перенос моего существующего кода, который импортирует различные полезные биты Javascript из других файлов с помощью ASP include операторов.
Включение некоторых простых вещей с помощью <--#incude file="somejsconstants.asp" --> сработало нормально и позволило мне получить доступ к константам из этого файла. Но моя попытка подключить сериализатор JSON с помощью <--#incude file="json2.min.asp" --> не сработала, а запуск версии json2.js, модифицированной таким образом, чтобы быть отдельной aspx-страницей, выдал ту же ошибку. (Ошибка компилятора - Объекты типа 'jscript_aspx' не имеют такого члена). Похоже, JScript.NET не нравится использование замыканий, почти вездесущей конструкции в современных библиотеках javascript.
Из сообщений выше ясно, что существует множество способов сериализации объектов JSON на платформе .NET, но мое чутье подсказывает, что если JScript.NET обгаживает Javascript, написанный Дугласом Крокфордом, то это причудливая, несовместимая крысиная нора, в которую не стоит вкладывать свое время. С таким же успехом я могу последовать за массой ASP.NET и использовать C#.