Станислав Макаров

Практическая польза - в читаемости кода. Когда начинаешь читать исходник, просматриваешь юзинги и понимаешь, какими сущностями тут собираются оперировать.

А касаемо производительности - вы путаете компиляцию и интерпретацию, а также using как импорт имен и include как вставку содержимого другого файла.
Компилятор C# разберется с используемыми именами еще на стадии компиляции, поэтому он либо все их однозначно сопоставит с полными именами, либо выдаст ошибку. Конечно, когда импортируется меньше имен, компиляция будет немного быстрее, но это а) не влияет на производительность скомпилированной сборки; б) куда менее важно, чем читабельность кода, которая пострадает первой от 30-ти using-ов в одном файле.

Кстати, большое количество using это еще и сигнал о необходимости разбить исходный код на несколько файлов.

Подумайте над таким вариантом:
1) руками на карте грубо рисуете геометрию области (не обязательно прямоугольную), где фигурирует четко один трек (чтобы выделить массив точек, относящихся к одному треку). Врядли это просто сделать автоматически
2) бьете всю обозначенную вручную область на небольшие квадраты. Для каждого из таких квадратов будем искать среднее значение. Вот как раз тут и можно учесть тот самый шестой знак - т.е. построить квадраты так, чтобы в координатах границ квадрата шестой знак был равен нулю (т.е. на каждый квадрат будет 10 возможных значений реальной координаты).
3) для каждого квадрата делаем выборку координат из базы (если есть нормальный пространственный индекс, должно быть быстро). Если в квадрат не попала ни одна координата, пропускаем его (таких будет большинство, но их будет тем меньше, чем точнее вы вручную выделили область одного трека). Если попала хотя бы одна (а лучше несколько) - считаем среднее значение. Это среднее значение становится частью мастер-трека.

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

Protocol Buffers?
На Ноду: https://www.npmjs.com/package/protobufjs
На дотнет: www.nuget.org/packages/protobuf-net (не уверен, что этот пакет - лучший вариант, но вроде самый популярный)

Сейчас Шарп с WPF-ом и C++ с Qt-ом примерно равны по возможностям. Изначально WPF конечно был более продвинутым, но с момента его появления прошло уже много времени, а развивается он слабо, поэтому Qt его "догнал".
Но для большинства разработчиков все упирается в язык. Не все хотят учить второй язык для изучения технологии, не все хотят учить C++.

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

Для подбора N предметов разного цвета (ну или просто N различных цветов для M >= N различных предметов) найдите подграф с нужным количеством вершин, где все вершины связаны друг другом, включающий некоторые заданные вершины. Например, подграф из 3-х вершин, содержащий вершину "зеленый", при этом каждая вершина подграфа связана с другой вершиной ребром (т.е. длина пути всегда равна 1). Это значит, что в комплекте у вас будут только совместимые друг с другом цвета, один из которых - зеленый.
Можно увеличить длину пути до 2-х, тогда, если белый будет совместим с черным, черный - с зеленым, но белый НЕ совместим с зеленым, то тем не менее такой набор цветов будет приемлемым.

попробуйте

MetadataTag tag = new MetadataTag(FREE_IMAGE_MDMODEL.FIMD_COMMENTS);
tag.Key = "new Tag";
tag.Value = "foobar";
FreeImage.SetMetadata(FREE_IMAGE_MDMODEL.FIMD_COMMENTS, dib, "new Tag", tag);
FreeImage.SaveEx(dib, ofd.FileName);

Есть соображение, что MetadataTag, который вам отдала либа, не предназначен для изменения "на ходу" и либа не следит за тем, что вы записали в существующий тег что-то новое. Скорее всего new ImageMetadata делает "снимок" метаданных, которым затем можно пользоваться независимо от картинки (нужно точнее - см. документацию). Поэтому попробуйте ставить тег явно с помощью SetMetadata.

> "ref or out argument must be an assignable variable"
вам же пишут - то, что вы передаете не является переменной (ну точнее, переменной, в которую можно что-то присвоить). Ссылка из переменной pet, скастованная к Animal - это уже "значение", а не "переменная". Вы можете запихнуть что-либо в pet, но не можете в (Animal)pet - т.к. это не переменная, а выражение, значение которого можно вычислить.
Как уже отметили выше, ref и out требуют передачи ПЕРЕМЕННОЙ в которую можно (и нужно в случае out) что-либо записать. И не имеет значения - ссылочный тип имеет переменная или тип-значение. Если вы передадите ref Dog, то в этот параметр можно будет записать ссылку на объект Dog, если передадите ref int - сюда можно будет записать int.

Видите ли в чем дело - нормализация это не столько для СУБД и не для приложения ее использующего. Это больше для вас, для разработчика (БД и/или приложения), и для целостности и согласованности данных.

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

Именно по причине несовпадения двух структур БД: максимально нормализованной, удобной для разработчика/проектировщика, и оптимизированной для выполнения запросов - стандартный цикл проектирования БД включает в себя этап нормализации до опредленного уровня (хотя бы до 3нф), и последующей денормализации для ускорения конкретных запросов (также, как и построение необходимых индексов). Т.к. денормализация требует усложнения логики работы с базой (те самые обновления в нескольких местах), эту логику (чаще всего это хранимки или триггеры, реже - на стороне приложения) нужно реализовывать максимально аккуратно и формально. Это похоже на написание кода на высокоуровневом языке и последующая его компиляция под конкретную платформу с максимальными оптимизациями. Единственное важное отличие - особенности целевой платформы известны заранее, и компилятор, учитывающий эти особенности, можно написать один раз, а вот особенности работы БД в каждой задаче - свои, поэтому в каждом случае нужно проводить работу по оптимизации БД с нуля.

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

> Как вообще в C# присваивание переменных происходит, в java вообще все отлично там все является указателем, и сохранить ссылку на какой то элемент очень просто, как с этим тут?
Читайте про reference-types (типы-ссылки) и value-types (типы-значения) - от этого и зависит семантика присваивания.

О каком ListView речь идет? WPF или WinForms?

Если бы это было можно, никто б тогда не парился поисками уязвимостей для протроянивания машин. Достаточно было бы запустить cmd или powershell с нужными параметрами.
Проще написать инструкцию юзеру, или как посоветовали, батник. Ну или там, ярлык виндовый высылать (хотя конечно стопудов антивирусом порежется).

Сложно понять, чего вы хотите добиться. GetFiles - это функция? Она уже определена? Тогда надо так:

vector<string> files = GetFiles(path, pattern, AllElements);

То, что вы делаете сейчас - это создание объекта типа vector с передачей его конструктору трех параметров: path, pattern, AllElements

EDIT: Обновленный код из вопроса компилится без проблем (если определить функцию GetFiles): ideone.com/0RrK6x , нужно уточнить, где ошибка компиляции и посмотреть другой код.

Короткий ответ на ваш вопрос: Code First, Mappings.
Длинный ответ: вам действительно нужно разобраться, что называть моделью.
Лично я убежден, что модельные классы, представляющие из себя DTO - это по-любому anemic data model, а анемичная модель - это в 90% случаев нехорошо. Поэтому, у вас два варианта: отказаться от генерации "по картинке" в пользу Code First (рекомендую), либо пойти по пути Евгений Колегов - сказать, что EF-овская модель - это и не модель, а так, граф примитивных объектов с get/set-ами, а настоящая модель - вот она, обертка над ними, с реальной бизнес-логикой и т.д.

> По сути эти модели - это DTO то есть просто объекты содержащие только данные. А как быть с логикой обработки этих данных? Она должна быть в контроллерах что ли?
Ну это тот же самый вопрос: нормальная модель должна содержать логику.
> в Asp.net mvc должны быть "тонкими", то есть не содержать особой логики.
В контроллере - минимум, там логика специфичная не для бизнес-процессов, а для процесса работы самого web api, т.е. определение того, что нужно сделать с бизнес-сущностями, чтобы удовлетворить запрос.
> Или надо писать еще и дополнительные контроллеры в которых будет сосредоточена логика работы с моделями?
не стоит, думаю в вашей задаче такой дополнительный слой совершенно излишен.

Резюме: модель вполне может и должна следовать обычным правилам ООП, известным уже лет 40 - данные и логика их обработки должны быть рядом друг с другом. Отделение бизнес-логики отдельно от модели - это такой своеобразный фетиш разбиения приложения на много-много слоев (на самом деле выделение веб-сервиса с четко определенным api - уже неплохой слой). Если вы чувствуете себя некомфортно от того, что у вас модель без логики, и не можете ее туда поместить - нужно менять инстурменты или вариант их использования. Первые версии EF - это первый блин комом, отсутствие поддержки Code First и нормальных маппингов считалось серьезной проблемой. Сейчас это уже давно в прошлом.
Бонусные варианты, если вы не связаны ограничениями:
1) генерация ТАБЛИЦ ПО КЛАССАМ, а не маппинг классов на таблицы: для кого-то этот вариант очень даже подходит, плюс упрощает менеджмент схемой БД: у вас всегда есть один источник сведений о схеме данных - это ваша модель. По ней можно всегда получить текущую SQL-схему;
2) если вам нравится отдельно следить за объектной моделью и за SQL (я вот именно так люблю), можете посмотреть и на другие ORM - NHibernate вполне себе торт. Сейчас конечно EF более популярна, ибо стандартная и раскрученная, но я 4 года назад выбрал NH для своего проекта из-за отсутствия неприятных ограничений (например, NH умеет мапать даже на приватное поле, а EF тогда не умел) и из-за наличия вменяемых механизмов маппинга.