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

IP-адрес это число. Для IPv4 - это 4 байта. Для IPv6 - это 16 байт.
Если нужен только v4 - тогда можно взять INT. Если нужно и то и другое, то
а) советую хранить оба адреса независимо, на время перехода они обычно доступны одновременно (если какой-то останется неизвестным - ничего страшного, пометите как NULL)
б) хранить в виде строки смысла не вижу вообще, БД это место для хранения данных, а не для интерфейс для просмотра, и ориентироваться надо на хранение. Кто хочет красиво вывести - пусть строит нужный запрос с препобразованиями, выше уже привели отличные функции.
в) храните в binary(4) и binary(16) чтобы иметь унифицированный подход (мне так было удобнее, советую и вам)
г) только не надо varbinary - размер адреса постоянен, никакого var быть не может. Типы данных с фиксированным размером (даже binary) намного легче в хранении и обработке, чем с переменным. Не мучайте СУБД не по делу.

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

А касаемо производительности - вы путаете компиляцию и интерпретацию, а также 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 , нужно уточнить, где ошибка компиляции и посмотреть другой код.