Wataru

Это очень плохая идея. Теперь пользователю придется искать функцию в 5 файлах, потому что она может быть в любом из них. Если же куски класса можно как-то логически сгруппировать, то надо разбить сам класс на несколько более мелких. Вынести часть функционала в вспомогательные классы или даже тупо функции.

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

Можно сделать так:

template <int a, int b>
class A {
    public:
    template<bool tmp = true>
    typename std::enable_if<a==b && tmp, int>::type F() {
       return 1;   
    }
};

...

A<1,1> a;
std::cout << a.F();  // OK.
A<2,100> b;
std::cout << b.F(); // Ошибка A<2,100> не имеет метода F().

Мне сложно объяснить, чтобы было понятно, почему работает именно это, но я попробую.

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

Далее, хотелось бы что бы просто работало вот это:

template<>
 typename std::enable_if<a==b, int>::type F()

Тут все понятно, enable_if не имеет type, если a неравно b. Шаблон никак не инстанциировать и метод не должен был бы генерироваться. Но это было бы слишком просто.

Вместо этого, надо там завести какой-то вообще ненужный как бы параметр шаблона tmp, и обязательно использовать его в enable_if. Это потому что если в этом шаблоне не будет никак использоваться параметр шаблона, то SFINAE не срабатывает, и вылезает ошибка компиляции.

В общем случае - будет.
std::swap работает за константу:

Complexity
1) Constant.

Присвоение за линию:

Complexity
1) Linear in the size of *this and other.

Edit: это если присваемые штуки - вектора. Или какие-то большие объекты с семантикой перемещения. Если у вас тупо числа, то одно присвоение будет быстрее swap.

Сначала каждую строку resize до размера size()+w0+w1. Потом сдвигайте элементы на w0 позиций вправо (цикл надо гнать с конца). Потом заполните пустые места нулями.

То же самое в самом векторе векторов. Только вместо чисел надо сдвигать вектора на h0 позиций. На пустые места надо будет записывать std::vector(n+w0+w1, 0);

Edit: А вообще, тут и добавлять в массив ничего не надо. Вы нужный вам ответ можете нулями прямо во время вывода добить.

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

Чтобы это исправить нужно или засунуть все в h файл, или в cpp файле прописать специализации шаблона со всеми типами, которые где-либо еще используются, вот так:

using A<int>;
using A<double>;
// etc

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

И кстати, в вашем случае вам совсем нет смысла делать вложенный класс шаблоном. Он уже в шаблоне же, просто используйте внутри тип T.

Окройте файл в ifstream в бинарном режиме и читайте 2 байта через read.

Или используйте fread. Читайте 2 байта в буфер длинной 2.

Аккуратно расставьте отступы. У вас там логика if else напутана, и программа делает совсем не то, что бы вам хотелось. Кроме того, посмотрите внимательно на warning-и от компилятора (он точно скажет, что power иногда не возвращает никаких значений, хотя вам кажется, что return есть во всех ветках if else). Это как раз потому, что у вас скобки не так расставлены и else относится совсем не к тому if, как вы хотели бы.

Это делается по нескольким причинам.

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

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

Во-вторых, иногда это делается и для удобства. Ибо в этих шаблонах параметры сами могут быть адски нагроможденными шаблонами.

А не проще ли так?

template <const std::size_t other_columns>
 Matrix<rows, other_columns, T> MultiplyOnMatrix(const Matrix<columns, other_columns, T>& matrix)

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

P.s. сказанное выше не относится к виртуальным функциям. Там указатель на функцию храниться в vtable в экземпляре класса и вызов через nullptr скорее всего упадет.

Да, большинство ресурсов выделяется динамически.

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

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

А так, для ускорения выделения памяти есть, например, аллокаторы на стеке: Заводится локальный массив и специальный менеджер памяти вместо выделения ее в куче, выделяет куски из этого массива. Но их не используют для хранения больших объемов данных по первой причине - это очень расточительно по памяти.

Edit: да, если вам нужно больше стека, можно сделать так, чтобы программа получала больше стека. В С++ это делается параметром линкера.

А зачем это делать? Чем вас 8 хедеров не устраивают? Если уж так хочется сэкономить строчки в коде пользователей библиотеки, то можно воспользоваться рекурсивностью препроцессора и сделать хедер с 8 инклудами. Копипастить код точно не надо.