likehood, мне надо будет отдавать пользователю ссылки на элементы массива. В данном случае тип элементов foo_local, о котором пользовает не знает и не узнает, так как он локальный.



Ну, не всегда. Особенно если они константные...


чем? уже созданным внешне массивом?


Как хочу? Дык вот я и хочу! Вызвать разные конструкторы для разных элементов массива. Но как? Проблема - инициализация массива!


Ы, тоже не мой выход. Некоторые данные должны остаться public.

Earnest, вариант threef'a не подходит. Он предлагает инициализировать надструктуру. Опять-таки - чем? У меня не POD-данные, чтобы их в инициализаторе прописывать между фигурными скобками... Задача - вызов конструкторов. И без локальных классов, мне потом надо будет эти ссылки на эти данные выводить наружу.

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

Если массив не константный, то никто не мешает писать в конструкторе структуры:
a[0] = XXX;
a[1] = YYY;
и т.д.
Нужно только позаботиться, чтобы элементы массива имели default-конструкторы.
Что ты передашь в надструктуру для инициализации - твоя проблема, хоть из файла данные читай.
Ты писал изначально о невозможности вызвать конструкторы для каждого элемента массива. Так вот, эта проблема решается в рамках описанного подхода.
А как ты разом передашь для разных элементов инициализирующие данные - совсем другая проблема.

Operator= не подходит... Уже говорил же ж. Если делать константными данными.

Решение с помощью закрытия данных и работы через функции принято. Вопрос, как вызвать конструкторы элементов массива. Без использования операторов=.

Просто абстрагируясь от моей проблемы: как вызвать <u>конструкторы</u> элементов массива. Не присваивания потом или через внешние структуры.
Сам факт. Нет - значит нет, дело же такое 

Вообще-то, в моем примере тип массива Foo*, так что никаких проблем. Приведение к базовому классу еще никто не отменял.

Соглашусь. Но проблема прямого вызова конструкторов не решена. Мне надо это запихнуть в массив без operator=. Если выдавать элементы по одному, то такое не выйдет.

Поля-массивы в классе

До сих пор в качестве полей мы использовали только скалярные переменные. Но в С++ нет запрета объявлять в классе поле-массив. Естественно, размер класса с полем-массивом увеличивается на размер массива. Однако использование массива в классе имеет некоторые нюансы, связанные с инициализацией . Начнем разбираться с этим вопросом на самом простом примере (листинг 2.23), в котором объявляются и инициализируются несколько полей-массивов.


В классе Arrays объявлено три поля-массива: m0, m1 и m2. Как видим, задать количество элементов массива можно либо явной константой, либо константным выражением со статическими и/или нумерованными константами, причем константы должны быть определены раньше массива. Задавать количество элементов поля-массива обязательно.
Конструктор без аргументов обнуляет массивы, выполняя цикл в теле. Такой способ инициализации поля-массива — в теле конструктора — является наиболее простым. Это позволяет присвоить элементам массива любые значения. Однако наиболее часто выполняется обнуление, поэтому для массивов разрешается применять инициализацию нулем. Тогда наш конструктор выглядит значительно проще:

Для массива объектов некоторого типа такая запись означает вызов конструктора по умолчанию (без аргументов), и не забудьте, что этот вызов выполняется для каждого элемента массива.
К сожалению, применение списков инициализации для полей-массивов этим и ограничивается — в скобках нельзя ничего указывать. Явная инициализация не проходит даже для символьных массивов. Например, если мы объявим в классе Arrays символьный массив

и попытаемся в списке инициализации конструктора присвоить этому массиву символьную константу,

то в системе Visual C++.NET 2003 получим сообщение об ошибке:
error C2536: 'Arrays::Arrays::s' :
cannot specify explicit initializer for arrays
нельзя определять явный инициализатор для массивов
Однако мы можем прописать в классе поле-указатель на символ

и инициализировать его символьной константой в списке инициализации конструктора, как показано выше.
Как это ни странно, но большие проблемы возникают при попытках объявить в классе константный массив встроенного типа! Как мы выяснили выше, константы не могут быть проинициализированы в теле конструктора и инициализируются только в списке инициализации конструктора. Однако для константного массива встроенного типа не работает даже инициализация нулем.
ПРИМЕЧАНИЕ
Этот вопрос практически не отражен в стандарте, поэтому компиляторы ведут себя по-разному. В системе Visual C++.NET 2003 выдается ошибка компиляции C2439, а Borland C++ Builder 6 выдает только предупреждение W8038 о том, что массив не инициализируется.

Не проходит и отмена константности. Например, мы пропишем массив m0 как константный, а в теле конструктора пропишем инициализацию в цикле

И система Visual C++.NET 2003, и Borland C++ Builder 6 откажутся компилировать такой цикл.
Удивительно, но для константного массива объектов не встроенного типа задавать инициализацию нулем разрешается. Для этого в классе должен быть определен конструктор без аргументов, который вызывается для инициализации каждого элемента константного поля-массива. Например, вполне можно инициализировать константный массив строк,

прописав в списке инициализации конструктора инициализацию «нулем» ss(). Как реально инициализируется такой массив, конечно, зависит от реализации конструктора по умолчанию.

SerpentVV, это все было к чему?

Может я плохо понял задачу, но в моем примере operator= не используется, присваивание идет через список инициализации.

Задача - вызов конструкторов для каждого элемента массива. Список инициализации работает только для POD-типов, тем более значения, передаваемые в конструктор, мне не известны в начале программы.

Ну так в моем примере передаваемые значения и вычисляются во время работы программы. Кстати, почему это список инициализации работает только для POD-типов?

Добавлено через 2 минуты и 53 секунды
Может мы говорим о разных вещах? 
Я говорю об этом посте.

Хм... приведи контрпример.


да... недосмотрел я тогда, видать. Возможно, это выход. Попробую применить. Спасибо.

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

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


Видимо, я тебя неправильно понял. Ты, наверное, под списком инициализации имел ввиду пример threef'а, а я подумал о другом. В таком случае согласен насчет POD-типов.


Разве ж это переборщил. Тут такие перлы иногда выдают...   

Это к тому, что в списке инициализации вызывается конструктор по умолчанию - для неPOD-типов.

Во-вторых, к тому, что о полях-константных массивах в стандарте нет практически ничего.

В третьих, несколько противоречивая постановка: инициализировать константный массив значениями, которые не известны в начале работы программы...
Тогда это - не константный массив, если значения констант неизвестны при компиляции...

Если есть желание просто защитить от изменений - нет нужны объявлять массив константным... Можно решить этот вопрос на уровне прав доступа...
 

Никаких противоречий...



Такой код тебя не смущает? А ведь значение явно не будет известно на этапе компиляции...
Так и у меня. У меня некоторые поля класса константные... Которые, естественно, инициализируются в конструкторе. Не по-умолчанию...

А в принципе, как минимум два пути решения вопроса уже озвучены.
1) с помощью прав доступа
2) с помощью локальных классов

Всем спасибо, тему можно закрывать.

Ага, понял... Логическая константность, естественно, не всегда равна физической...