При всем уважении к Робу Кеннеди он искажает представление о том, как C / C ++ обрабатывает многомерные массивы.
Рассмотрим int foo [10] [10] и int foo [100]. В обоих случаях foo - указатель на блок памяти, содержащий размер (int) * 100 байт.
Там есть тонкие различия между указателем int * и int foo [10] [10]. Особенно в отношении sizeof () и определенной проверки ошибок конкретного компилятора. Но при желании мы можем обращаться с ними взаимозаменяемо.
Тем не менее, leachrode не может передать аргумент 2 из getline () как "[10] [10]" . Он может передать "10 * 10 * sizeof (foo)" , где foo - это тип myArray . Он также может передать sizeof (myArray) , если он фактически объявлен как массив.
Переменная myArray НЕ обязательно должна иметь тип char . Однако ни один из байтов в блоке данных myArray не может иметь значение '\ n', если этот getline () вызов будет работать.
Лично я бы пошел с двоичным хранилищем. Например: (Предполагается, что inputFile является объектом iostream.)
inputFile.write( (const char *)myArray, sizeof(myArray) );
inputFile.read( (char *)myArray, sizeof(myArray) );
* ОДНАКО *, что предполагает, что вы читаете и пишете в двоично-совместимых системах. Мы делаем предположения о том, как ваш компилятор хранит этот массив в памяти. Различные компиляторы могут делать вещи по-разному. Проблемы с отступами и выравниванием могут создавать кроссплатформенные кошмары.
Было бы лучше, с точки зрения переносимости и будущего обслуживания, читать / записывать каждый элемент массива по отдельности! В коде это не намного сложнее. Скорость, iostreams буферизуются, и вы все равно связаны диском io ...
Ссылка: http://www.cplusplus.com/reference/iostream/
Запоздалая мысль: - IF myArray не элементарного типа (int [], double []), но вместо этого представляет массив объектов (с виртуальные члены) или указатели, вам понадобятся средства сериализации. Указатели не будут указывать на действительную память, когда они считываются обратно.