Я к тому, что так делать вообще не следует. Никогда! Как минимум, исключение нужно логгировать. В противном случае либо бросаются исключения не по делу, либо клиентский код - это минное поле и пора задуматься об архитектуре.
> Если вы считаете, что сможете "развернуть" знания С на другие контексты...то у вас этого не получится.
Знание модели памяти, устройства ООП, понятия стека и хипа, ложатся отлично на множество других языков. И, да, особенно это касается managed-языков, где памятью управлять вроде не нужно, но как работает среда исполнения нужно знать обязательно.
В С++ можно все =) Статический многомерный массив - это что? Непрерывный блок памяти, где строка идет за строкой. Мы можем взять указатели на первые элементы строк? Можем. А можем их объединить в массив указателей (на который будет указывать указатель на указатели)? Можем.
Вы же сам массив размещаете не в стеке, а в куче, что, по сути, является совсем иным сценарием.
littleguga: Я бы сказал в принципе стоит коммитить чаще, чтобы потеря работы между коммитами стоила недорого.
Если над фичебранчем работает больше одного человека - билд всегда должен собираться и работать адекватно, так что коммитить все-таки стоит лишь нечто завершенное.
littleguga: ИМХО, это не стоит даже коммитить. И уж тем более - пушить на некий общий сервер, откуда CI берет ветку на тесты. Зачем тестировать заведомо сломанный билд?)
alex_ak1:
> Я не особо отличаю библиотеку qt от IDE qt.
>В смысле они практически неразлучны, в этом смысле.
С чего это? Вполне успешно можно писать под Qt в VS, в то же время никто не мешает в QtCreator использовать компилятор VS.
> Вся эта qt-шная связка (возможно IDE) дают те самые странные и неожиданные глюки.
Без фактов - это просто субъективщина.
Вполне возможно, что проект был написан не по стандарту, но с использованием всяких локальных фич стандартной библиотеки VS, которые закономерно под GCC не существуют.