Нет,нельзя. Единственное, что ты можешь сделать с массивом — членом класса в плане инициализации, это инициализировать его "нулями" в списке инициализации
class A
{
public:
A():arr_()
{
}
private:
int arr_[10];
};
Of course, the code must be complete enough to compile and link.
Ну тогда уж лучше pack(push,1) | pack(pop).
Иначе может возникнуть ситуация, когда обычная pragma pack() сломает установки для другого файла.
Я пару недель назад такую же ошибку допустил — спасибо комрад Кодт поправил
А еще лучше вообще от этой прагмы избавиться, и воспользоваться обычным массивом...
Здравствуйте, Bell, Вы писали:
B>Здравствуйте, Анатолий Широков, Вы писали:
B>Ну тогда уж лучше pack(push,1) | pack(pop). B>Иначе может возникнуть ситуация, когда обычная pragma pack() сломает установки для другого файла. B>Я пару недель назад такую же ошибку допустил — спасибо комрад Кодт поправил B>А еще лучше вообще от этой прагмы избавиться, и воспользоваться обычным массивом...
Да, это уже пошли фичи зависимые от компилятора. GNU, Watcom не понимают pack(push, 1) pack(pop), поэтому надо условную компиляцию вставлять:
HANDLE_PRAGMA_PACK_PUSH_POP
Define this macro (to a value of 1) if you want to support the Win32 style pragmas `#pragma pack(push,<n>)' and `#pragma pack(pop)'. The pack(push,<n>) pragma specifies the maximum alignment (in bytes) of fields within a structure, in much the same way as the `__aligned__' and `__packed__' __attribute__s do. A pack value of zero resets the behaviour to the default. Successive invocations of this pragma cause the previous values to be stacked, so that invocations of `#pragma pack(pop)' will return to the previous value.
Lorenzo_LAMAS wrote:
> Нет,нельзя. Единственное, что ты можешь сделать с массивом — членом класса в плане инициализации, это инициализировать его "нулями" в списке инициализации > >
> class A
> {
> public:
> A():arr_()
> {
> }
> private:
> int arr_[10];
> };
>
VC7.1 не обнуляет — я как-то наступал на эти грабли, но тогда разбираться не стал. Кто неправ?
Здравствуйте, serb, Вы писали:
S>Добрый день
S>Подскажите как можно проинициализировать ааа в консруторе класса если она атрибут класса S>Если ааа локальная так S>
S> int aaa[3]={1,2,3};
S>
S>А если атрибут
Может так :
class A
{
int aaa[3];
static int _init_(A* pA)
{
static int _init_aaa[3]={1,2,3};
for(int i=0;i<sizeof(_init_aaa_)/sizeof(int);i++)
pA->aaa[i]=_init_aaa[i];
}
public:
A() { _init_(this); }
};
Кодт wrote:
> ME>VC7.1 не обнуляет — я как-то наступал на эти грабли, но тогда разбираться не стал. Кто неправ? > > Для POD он, вроде бы, и не обязан... А даже если и обязан, но не делает — возьми лучше boost::array.
Я специально посмотрел на boost::array<> когда этот топик появился. Он никак не инициализируется, т.к. у него нет конструктора! Оно и понятно — основная идея boost::array<> — прикрутить stl-like итераторы к обыкновенному C-массиву. Кроме того, boost::array<> может быть инициализирован при помощи синтаксиса, похожего на инициализацию C-массива.
Class array fulfills most but not all of the requirements of "reversible containers" (see Section 23.1, [lib.container.requirements] of the C++ Standard). The reasons array is not an reversible STL container is because:
— No constructors are provided
— Elements may have an undetermined initial value (see below)
— swap() has no constant complexity
— size() is always constant, based on the second template argument of the type
— The container provides no allocator support
It doesn't fulfill the requirements of a "sequence" (see Section 23.1.1, [lib.sequence.reqmts] of the C++ Standard), except that
— front() and back() are provided
— operator[] and at() are provided
Regarding the constructors there was an important design tradeoff: We could implement array as an "aggregate" (see Section 8.5.1, [dcl.init.aggr], of the C++ Standard). This would mean:
An array can be initialized with a brace-enclosing, comma-separated list of initializers for the elements of the container, written in increasing subscript order:
boost::array<int,4> a = { { 1, 2, 3 } };
Note that if there are fewer elements in the initializer list, then each remaining element gets default-initialized (thus, it has a defined value).
However, passing no initializer list means that the elements have an indetermined initial value.
It has no user-declared constructors.
It has no private or protected non-static data members.
It has no base classes.
It has no virtual functions.
The current implementation uses this approach. However, being able to have indeterminate initial values is a big drawback. So, please give me some feedback, how useful you consider this feature to be. This leads to the list of Open issues:
Do we want initializer list support or would the following be OK?:
int data[] = { 1, 2, 3, 4 }
array<int,5> x(data); or array<int,data> x;
Could "{ ... }" be used portably instead of "{ { ... } }" to initialize values?
8.5.1 (11) of the Standard seems to allow it; however, gcc 2.95.2 prints a warning message.
Any way to have determinate initial values and initializer list support?
Static_casts for reverse iterator stuff?
Здравствуйте, MaximE, Вы писали:
ME>Я специально посмотрел на boost::array<> когда этот топик появился. Он никак не инициализируется, т.к. у него нет конструктора! Оно и понятно — основная идея boost::array<> — прикрутить stl-like итераторы к обыкновенному C-массиву. Кроме того, boost::array<> может быть инициализирован при помощи синтаксиса, похожего на инициализацию C-массива.
Вот ведь блин какой!
Тогда придётся делать что-то своё