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

И этот массив заполнен некоторыми строковыми значениями, но не полностью, а только до некоторых значений.

Это предположение неверно. Массив не бывает заполнен частично, до некоторых значений. В массиве всегда есть все значения, просто при создании массива они устанавливаются в дефолтовые.
Вам нужно хранить ваши значения в структуре переменного размера, например в списке (List).
Либо, раз уж у вас значения строкового типа, вы можете воспользоваться тем фактом, что строка - это ссылочный тип, и поэтому может иметь значения null. Вы можете идти по элементам массива до первого встретившегося null и считать его первым "незаполенным" элементом, если это подходит для вашей задачи (правда, тогда это придется делать каждый раз заново).

Для "изучения" вещей, таких как IDE, в которых и изучать то нечего, есть официальная документация. Официальная документация к продуктам Microsoft, имеющих отношение к разработке ПО (VS, TFS, библиотеки и прочее), находится на специальном портале, называемом Microsoft Developer Network (MSDN).

select route.name, departure_city.name, arrival_city.name
from
    route
    join city departure_city on route.departure_city_id = departure_city.id
    join city arrival_city on route.arrival_city_id = arrival_city.id

std::placeholders

btn->onClick = bind(&Player::play, this, std::placeholders::_1);

Beyond Compare

1) вы так легко считаете память, выделяемую под ваши кубы). Я думаю это весьма далеко от истины, т.к. лично я даже предположить не смогу, что конкретно происходит при создании дотнетовского объекта и сколько конкретно он потребует памяти;

2) вы используете инструмент не по назначению. WPF - это для относительно малого числа граф. объектов (десятки, сотни) с высоким уровнем интерактивности для каждого из них. Иными словами - для интерфейсов. В интерфейсах есть небольшое количество высокоинтерактивных объектов - кнопок, скроллов, комбобоксов, и именно для таких сценариев WPF и оптимизирован. Вам с 10К кубами уже давно пора брать Direct3D и не мучаться. Это я вам не с потолка говорю, мы тоже когда-то пытались использовать WPF-шную двухмерную графику для двухмерной отрисовки, но быстро поняли, что его инфраструктура слишком тяжелая для нашей задачи. Вы замучаетесь в попытках это все оптимизировать.

Вы невнимательно читали про наследование (или читали в плохом источнике).

Логически (т.е. с точки зрения самой идеи) наследование (причем, любое, public и другие) подразумевает, что реализация базового класса станет частью реализации дочернего. Приватные поля класса - это часть его реализации.

Технически, наследование в C++ подразумевает наличие подобъекта базового класса в объекте класса-наследника. Т.е. у вас в каждый объект Two помимо его собственных полей (в вашем примере их нет) запихиваются все поля Base (и так с каждым базовым классом, если их несколько), по принципу матрешки. НЕВАЖНО, как указали уже в первом ответе, что вы не имеете к ним доступ из класса-наследника. Важно, что они есть, и методы класса Base могут ими спокойно пользоваться, чтобы выполнять свою работу.

1) переделайте/сконвертируйте изображение так, чтобы это был Drawing:

<GeometryDrawing Brush="#FF8B0000">
      <GeometryDrawing.Geometry>
        <PathGeometry ....... />
      </GeometryDrawing.Geometry>
    </GeometryDrawing>

Если PathGeometry несколько, используйте DrawingGroup.
2) поместите полученный XAML в ресурсы;
3) попробуйте мой велосипед для того, чтобы поместить изображение в кнопку:

<Image Source="{Binding Source=путь_к/картинке.xaml, Converter={StaticResource ResourceUriToDrawingImageConverter}}" />

Код конвертера:

public class ResourceUriToDrawingImageConverter : IValueConverter
	{
		public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
		{
			Uri uri =
				value is Uri ?
					value as Uri :
				value is string ?
					new Uri(value as string, UriKind.RelativeOrAbsolute) :
					null;

			if (uri == null)
			{
				throw new Exception("Invalid URI value");
			}

			StreamResourceInfo sri = Application.GetResourceStream(uri);
			if (sri == null)
			{
				throw new Exception("Resource not found");
			}

			using (Stream stream = sri.Stream)
			{
				var drawing = XamlReader.Load(stream) as Drawing;
				if (drawing == null)
				{
					throw new Exception("Resource cannot be converted to drawing");
				}

				return new DrawingImage(drawing);
			}
		}

		public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
		{
			throw new NotImplementedException();
		}
	}

P.S. Следите за репой https://github.com/Nipheris/SharpVectors.MSBuild - там скоро появятся MSBuild-таски для конвертирования SVG прямо во время сборки проекта.

Т.е. нужна некая философия

А какие книги вы уже пробовали читать, раз такое спрашиваете?

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

Все это дает вам набор простых правил:
1) выбрасывать исключение нужно тогда, когда вы не собираетесь обрабатывать возникшую ситуацию в рамках текущего алгоритма. Иными словами, для работающей в данный момент функции эта ситуация - "исключительная". Пример: вы пишете функцию для чтения GIF-файла в Bitmap, и по ходу чтения проверяете соответствие получаемых данных формату GIF-файлов (например, убеждаетесь в наличии GIF89a в начале файла). Если вдруг вы видите, что формат файла нарушен, то вам ничего не остается кроме как выбросить исключение, т.к. вы не можете продолжить выполнение основного алгоритма - считывание файла. Внутри функции считывания вы не знаете заранее, как вызывающий код захочет обработать эту проблему, вам и не нужно это знать;
2) перехватывать исключение конкретного типа нужно тогда, когда в задачу текущего кода входит и обработка ошибок тоже. Иными словами тогда, когда исключение в вызванном коде - лишь один из вариантов нормальной работы вызывающего кода. Вернемся к примеру с GIFками: если для библиотечной функции чтения файла нарушение формата - это критическая проблема, то для вызывающего эту функцию GUI-приложения это нормальная ситуация - ее можно и нужно обработать, выдав пользователю соответствующее сообщение, или просто пропустить файл, если обрабатывается сразу несколько картинок. Или например, если вы пишете веб-сервис, вы врядли хотите, чтобы весь сервис прекратил работу из-за ошибки при обработке какого-то одного запроса. Поэтому в веб-сервере, раздающем файлы вы, к примеру, можете перехватывать все FileNotFound исключения, и выдывать ошибку 404, а на все остальные исключения внутри обработчика запроса - ошибку 500 и в обоих случаях писать в error.log.

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

Отличный пример разных подходов - методы Parse/TryParse у числовых типов в дотнете. Первый возвращает значение и выбрасывает исключение, второй записывает значение через выходной параметр, возвращает bool и НЕ выбрасывает исключение. "Try" в названии второго метода подчеркивает, что для этого метода неудача при попытке распарсить число из строки - НОРМАЛЬНАЯ ситуация, и метод в этом случае вернет false. Для метода Parse напротив, такая ситуация будет исключительной, т.к. ему просто-напросто нечего будет возвращать, и дальнейшая нормальная работа кода, в том числе вызывающего, невозможна.
Поэтому метода TryParse чаще используют тогда, когда вероятность ошибки высока и ее обработка - одна из ветвей алгоритма. Например при считывании пользовательского ввода мы сразу можем попросить пользователя исправить введенное значение.
С другой стороны, Parse применяется если ошибка маловероятна, мы не готовы ее обработать и лучше прервать всю операцию целиком. Например если мы получили от сервера невалидный ответ, мы не попросим его исправить этот ответ. Дальнейшее общение с сервером лучше прервать, т.к. имеет место нарушение протокола и можно наломать дров.