Peter_P насчет второго примера, это описание конструктора класа со списком инициализации. Как известно, в момент вызова конструктора класса инициализируються все поля класса, мы можем явно указать, какими значениями инициализировать поля:
Это описание коструктора classname::constructor, в С++ имя конструктора точно такое же как имя класса.
После двоеточия идет список инициализации:
В С++ семантика каждого типа - это семантика объекта, т.е. как для типа repLocation(1) мы вызываем конструктор и тем самым инициализируем его, точно также иницаилизируем простую переменную repIsOn.

Фактически получаем указатель на массив, который являеться статическим членом класса. Все статические члены и методы класса создаються во время старта программы и уничтожаються во время ее закрытий, еще не имеют указателя this (потому как существуют в независимости от созданого экземепляра класса). Доступ к ним возвожен так:

Перегруженный конструктор.

И еще, тут видимо опечатка:

Добавлено спустя 6 минут, 6 секунд
Почему бы и нет? Какая это рекурсия? Это не рекурсия, как по твоему списки объявляються?


Слово const после объявления метода класса значит лишь то, что этот метод не может изменить ни одного члена класса, кроме тех, которые объявлены как mutable, по типу

Добавлено спустя 3 минуты, 27 секунд
PS вообще-то лучше читать стандарт, а не книгу там где показан плохой стиль программирования

PPS если location это класс, то его лучше передавать не по значению, а по константной ссылке:

Daemon
Спасибо - более менее начал разбираться.
Эта книга не совсем про программирование - просто некие принципы автор комментирует кусками кода.

помоему массив в DOS не может быть больше 64 килобайт а тут 200*200*4=160 кбайт
Добавлено спустя 3 минуты, 32 секунды
по первому пункту:
ты запускаеш прогу из среды программирования?
откуда прогу запустил то и есть её домашняя папка
и все файлы в етой папке можно читать по относительному пути
среда наверняка компилит файл куда-нить в projects-здесь и косяк

У меня вопрос.
Почему все мои проги (С++) под консоль занимают 1,2 Мб??? Юзаю Dev-C++. Когда писал на чистом Си все проги занимали не более 100 кб? Тоже в Dev-C++ было дело.
Как мне сделать размерчик то поменьше?

Лучшим выходом было бы выбрать другой компилятор. Лучше всего вообще писать под линукс, но если не хочется, то установить нормальную DE под венды. Имхо, в данный момент такой является VS2003 или 2005. Если и этого делать не хочется, то посмотреть в настройках твоей среды опции компилятора. В частности, убрать опции по отладке (debug), можно попытаться настроить проект так, чтобы исполняемый файл использовал DLL, не включая их в себя статически.

dimonpc2004 ты включаешь отладочный данные в ехе.

dimonpc2004 Заставит компилятор не включать неиспользуемы функции и переменные. заставить отключить динамическое определение типов, если ты ег оне используешь... Это как минимум

mein А в Linux и того меньше

Есть ли какая-то принципиальная разница в использовании new/delete и alloc/realloc/free? Почему функции alloc, realloc и free считают устаревшими и есть ли способ изменить размер динамически выделенной памяти не используя realloc?

qasz Есть конечно. malloc/calloc просто выделяют память, но не ицициализируют объект ( не вызывают конструктор для не POD типов) и free/cfree не вызывают деструктор. new/delete выполняют. такие операции, operaton new и operator delete не выполняют.
Нету, для этой цели нужно использовать контейнеры из STL.
Добавлено спустя 4 минуты, 19 секунд
Одну причину я уже назвал. Вторая - то, что использование realloc может нести серьезные накладные расходы, потому как realloc если не может изменить размер выделенной памяти - выделяет новую область требуемого размера и выполняет копирование, плюс по этому причине realloc может работать не корректно для не POD типов.

Daemon
побробнее можно, может я что-то не понял


Это почему же. Вполне современый и по моему единственный способ(если уж в глуб библиотеки смотреть)

почему не работает такое:

VC говорит что не может конвертнуть 'wchar_t [100][100]' to 'wchar_t ** . Собственно почему и как мне поступить в таком случает, если надо передавать двумерный массив.

nickyoz Потому как при копировании(если будет происходить копирование) realloc не будет вызывать конструкторов/деструкторов, в зависимости от того какие действия в них происходят realloc может работать, а может и не работать для твоего типа. И вообще копировать не POD типы с помощью memcpy строго не рекомендуют.
mein ну я думаю к этому времени ты и сам разобрался
У тебя есть указатель на первый элемент. В ф-ции нужно передать указатель на указатель, так организуй
xxx(&buf[0]);
Если будет компилятор выпендриватся:
xxx(reinterpret_cast<wchar_t **>(&buf[0]));

Daemon ещё не разобрался .

Оно, то, компилируется, но не работает - неправильно доходит указатель.

Что-то неработает корректно, при попытке обращения к элементу происходит ошибка
Два выхода или объявляй в программе не двумерный массив, а wchar_t **buf; или передавай массивы как рекомендует стандарт void xxx(wchar_t x[][100])
Добавлено спустя 1 минуту, 17 секунд
Или используй vector
Добавлено спустя 3 минуты, 4 секунды

Тогда посмотри вывод:


И как оно еще не работает Тут другая причина.

Daemon А. Ну это да. Применение этих функций к объектам более сложной природы, чем заложено в чистом С конечно недопустимо.

Daemon
пока сделал через xxx(wchar_t x[][100]) - работает, но выглядит страшно. vector для такой простой ситуации не охота юзать.
а вот из примера я высмотрел другую весчь:

А именно параметр argv . Это как понимать ?

mein Ну это массив указателей на char или wchar_t так передается (массив строк короче) В С унарные операторы справа на лево интерпритируются.