Если класс Document реализует интерфейс IDisposable, то будет лучше завернуть конструкцию
aDoc = new…
// work with aDoc
aDoc.Close();
в более короткую и корректную с точки зрения детерминированного освобождения ресурсов:
using (Document aDoc = new ..) {
}
Если же окажется, что Document не имплементирует данный интерфейс, то тогда можно хотя бы проэмулировать это поведение:
Document aDoc = null;
try {
aDoc = new…
//
} finally {
if (aDoc != null)
aDoc.Close();
}
Это хорошо, конечно, если наши институты и университеты перенимали бы у иностранных коллег хороший опыт и учились бы на чужих ошибках. Однако, часто случается так, что в стремлении перейти к новым стандартам выходит«хотели как лучше, а получилось как всегда». К примеру, у нас в универе сейчас идет активный переход на БРС (бально-рейтинговую систему). Т.е. каждый студент получает некие баллы (по любым предметам) и по результатам суммирования ставится оценка. Но оценка ставится и в обычной форме (2-5) и рядом с кол-вом баллов. Вроде бы все прекрасно и всем должно быть хорошо. Однако на практике это приводит к тому, что начинается беготня за баллами вместо стремления к разумному-доброму-вечному. Причем в некоторых случаях доходит до абсурда, когда преподаватели (физ-ра, военная подготовка вынуждены ставить какие-то баллы — но нет никаких критериев оценки) — не знают, что им делать. Студенты, в свою очередь, ставят перед собой приоритет не в виде накопления знаний, достаточных для сдачи экзамена/зачета, а в виде накопления баллов. В результате — уровень подготовки снижается, а уровень социальной напряженности растет. Все недовольны. А на консультациях обсуждаются не вопросы, связанные с тематикой предмета, а с тем, каким же образом будут расставлены те или иные «Баллы». В конечном итоге, для обычных людей слово «Балл» становится противным и ругательным в лексиконе.
На однопроцессорных машинах такое навряд ли случится благодаря механизму синхронизации кешей, но именно на многоядерных вполне вероятно, поскольку, если я не ошибаюсь, в многоядерных процессорах проблема синхронизации кешей отодвинута на второй план в угоду производительности (т.к. каждое ядро имеет свой кеш), и синхронизацию необходимо осуществлять специальным образом.
Быть может, здесь небольшая хитрость, связанная с тем, что как volatile помечен указатель на массив, а элементы этого массива не являются защищенными от кеширования в процессоре. Тогда вполне может возникнуть ситуация, когда один поток присвоит элементу первого массива единицу, прочитает нуль из второго (второй массив еще не был изменен вторым потоком). А во время обработки этого индекса вторым потоком поток бы рад прочитать единицу (как логически правильное значение, ведь первый поток уже занес туда 1), да кеш процессора подсовывает ему нуль, и в результате оба значения остаются нулевыми, а потоки шагают дальше (расходятся, потому что первый поток шагает от начала к концу массивов, а второй — наоборот).
Да, конечно это можно сделать, но мне кажется, это — не очень элегантный способ для простых действий (по сути эквивалентен описанному мной примеру с Delphi). К тому же, при использовании готовых решений мы лишаемся гибкости, которую приобретаем при написании собственных небольших (но полезных) решений.
Я бы назвал это интерпретацией предкомпилированного (если можно так выразиться) кода. Что-то вроде псевдокода, в котором роль инструкций выполняют элементы (операнды и операции) в постфиксной нотации. Интерпретацией бы это было, если бы сразу из строки переводилось в результат. Здесь же — нечто среднее.
Насчет генерации IL-кода — хорошая идея, которая уже фигурировала в комментариях, спасибо, я подумаю над этим.
Спасибо за отзыв )
Спасибо за интересный способ, позволяет несколько по-новому взглянуть на наш инструментарий ) Однако классические алгоритмы и умение их применять никто не отменял ) Тем более, если своя реализация может обеспечить более гибкий механизм для контроля каждой стадии анализа / вычисления. К примеру, в собственном парсере-велосипеде можно рулить как выражением в целом, так и отдельными его частями (например, оптимизировать выражение за счет предвычисления констант). В общем, проблема выбора между своей собственной разработкой и использованием готовых решений как всегда актуальна.
Обратная польская нотация, постфиксная запись, ПОЛИЗ (польская инверсная запись) — это способ представления выражений, а мы говорим об алгоритме его получения из обычной, инфиксной записи.
> Суть метода 2х стеков (наверняка у него есть красивое научное название.)
Да, судя по всему, это вариант алгоритма Дейкстры «сортировочная станция» Преобразование из инфиксной нотации
Привыкать к прелестям интегрированных отладчиков — тоже не очень. Потому что рано или поздно в жизни любого разработчика может возникнуть ситуация, когда отладка в таком удобном режиме будет недоступна. И в этом случае выручает логгер ) Кстати, при отладке многопоточных приложений механизм логирования в любом случае необходим.
Или NLog, там как раз я видел аналогичный функционал (консоль + раскраска сообщений), правда пока не пользовался. А теперь, после просмотра скриншота, наверное, попробую ) Автору спасибо, полностью поддерживаю его в деле использования логирования на всю катушку, в любых приложениях.
Я старался сделать код таким, чтобы он одновременно был не слишком сложен в использовании и универсален в смысле возможности добавления новых операций. Возможно, с первого взгляда кажется сложноватым, но спасибо за отзыв, есть над чем подумать. )
Нет, это же не компилятор в MSIL. Но эта возможность реализуема, если прикрутить генерацию IL по заданному CompiledExpression. Можно посмотреть PostSharp, там вроде бы есть такой функционал.
Мне кажется, что статическая типизация языка в данном случае не слишком сильно влияет на возможность допустить ошибку, написав уязвимый код. Такого рода логические недочеты языком навряд ли смогут регулироваться без специальных средств. Так что нужно проверять себя, на каждом участке кода пытаясь узнать — возможно ли возникновение нештатной ситуации и каким образом её можно предотвратить.
Спасибо за информацию. Жаль только, что не описаны основные методы предотвращения таких ошибок. Интересующимся могу предложить пролистать книгу «Защищенный код» из боекомплекта разработчика microsoft. Недавно видел её в Pdf на русском языке, где-то на torrents.ru. Но в этой книге, по большей части, ориентация на Windows и платформу .NET.
aDoc = new…
// work with aDoc
aDoc.Close();
в более короткую и корректную с точки зрения детерминированного освобождения ресурсов:
using (Document aDoc = new ..) {
}
Если же окажется, что Document не имплементирует данный интерфейс, то тогда можно хотя бы проэмулировать это поведение:
Document aDoc = null;
try {
aDoc = new…
//
} finally {
if (aDoc != null)
aDoc.Close();
}
Алилуя
Насчет генерации IL-кода — хорошая идея, которая уже фигурировала в комментариях, спасибо, я подумаю над этим.
Спасибо за отзыв )
Да, судя по всему, это вариант алгоритма Дейкстры «сортировочная станция» Преобразование из инфиксной нотации
// по традиции
Console.WriteLine(«Hello, habr»);