Добрый день!

Правильно ли я понимаю, что приведенный ниже пример (точнее,
отсутствие вызовов деструкторов) действительно иллюстрирует баг?
Ключевой момент — глобальный массив объектов шаблонного класса.

В 4.0.0 деструкторы вызываются, но это слишком продвинутая
для меня версия. Не известен ли кому-нибудь ID этого бага,
чтобы попытаться определить, какая самая старая
версия компилятора ему не подвержена?
Если обладатели 3.4.4 смогут проверить пример
на своем компиляторе — буду очень признателен.

/tmp/order >cat tst.cpp
#include <iostream>

template <class T>
class MainGlobaler
{
public:
MainGlobaler(char *) {std::cout << "Main globaler constructor" << std::endl;}
virtual ~MainGlobaler() {std::cout << "Main globaler destructor" << std::endl;}
};

static MainGlobaler<std::string> MgArr[] =
{
MainGlobaler<std::string>("Klava"), MainGlobaler<std::string>("Slava")
};

int main(int argc, char **argv)
{
std::cout << "Top of main" << std::endl;
}
/tmp/order >g++ tst.cpp
/tmp/order >g++ -v
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: /space/gcc-3.4.3/configure
Thread model: posix
gcc version 3.4.3
/tmp/order >./a.out
Main globaler constructor
Main globaler constructor
Top of main

У меня все работает:

c:\home\zxc>a
Main globaler constructor
Main globaler constructor
Top of main
Main globaler destructor
Main globaler destructor

c:\home\zxc>g++ -v
Reading specs from c:/Program Files/CodeBlocks/bin/../lib/gcc/mingw32/3.4.2/spec
s
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable
-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --e
nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-ja
va-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchroniz
ation --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)

c:\home\zxc>

P.S. Попробуй выводить с помощью printf() и делать fflush(stdout), вполне может быть что вывод буферизуется.

Здравствуйте, sch, Вы писали:

sch>P.S. Попробуй выводить с помощью printf() и делать fflush(stdout), вполне может быть что вывод буферизуется.

После завершения программы stdout будет зафлушен автоматом ИМХО

Здравствуйте, sch, Вы писали:

sch>У меня все работает:
[skipped]
sch>gcc version 3.4.2 (mingw-special)

Интересно.

Осталось понять, какое отличие принципиально —
в платформе (у меня linux с 2.4.20 и с 2.6.не_помню)
или в версии компилятора (у меня 3.4.3 и 3.2.2).

sch>P.S. Попробуй выводить с помощью printf() и делать fflush(stdout), вполне может быть что вывод буферизуется.

Я попробовал заменить потоковый вывод на fprintf в stderr. Не помогло.


Коллеги!

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

Здравствуйте, ilejn, Вы писали:

I>Коллеги!

I>Поскольку ситуация становится еще более занимательной,
I>чем мне казалось в начале, очень прошу
I>провести эксперимент со своими ggc'ями и
I>поделиться результатами/высказать соображения.

Фигня какая-то.

[kemm@redsun cpp]$ g++ -Wall -W -o tstt tst.cc
tst.cc: In function `int main(int, char **)':
tst.cc:20: warning: unused parameter `int argc'
tst.cc:20: warning: unused parameter `char ** argv'
[kemm@redsun cpp]$ ./tstt
Main globaler constructor
Main globaler constructor
Top of main
[kemm@redsun cpp]$ g++ -v
Using builtin specs.
gcc version 2.95.4 20020320 [FreeBSD]
[kemm@redsun cpp]$ rm tstt
[kemm@redsun cpp]$ g++34 -Wall -W -o tstt tst.cc
tst.cc:20: warning: unused parameter 'argc'
tst.cc:20: warning: unused parameter 'argv'
[kemm@redsun cpp]$ ./tstt
Main globaler constructor
Main globaler constructor
Top of main
[kemm@redsun cpp]$ g++34 -v
Reading specs from /usr/local/lib/gcc/i386-portbld-freebsd4.11/3.4.5/gcc/i386-portbld-freebsd4.11/3.4.5/specs
Configured with: ./..//gcc-3.4-20050920/configure --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=34 --libdir=/usr/local/lib/gcc/i386-portbld-freebsd4.11/3.4.5 --with-gxx-include-dir=/usr/local/lib/gcc/i386-portbld-freebsd4.11/3.4.5/include/c++/ --disable-shared --prefix=/usr/local i386-portbld-freebsd4.11
Thread model: posix
gcc version 3.4.5 20050920 (prerelease) [FreeBSD]

Здравствуйте, Kemm, Вы писали:

K>Фигня какая-то.
<поскипано>
Та же фигня на gcc 3.4.2 (FreeBSD 5.x), и на 3.3.2 (RedHat какой-то)

Здравствуйте, ilejn, Вы писали:

I>Коллеги!
...
I>провести эксперимент со своими ggc'ями

$ g++ main.cpp
$ a.exe

Main globaler constructor
Main globaler constructor
Top of main
Main globaler destructor
Main globaler destructor

$ g++ --version

g++ (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.

Привет.
Прошу обратить внимание где находится массив.

[ks@const:~]% cat aaa.cpp
#include <stdio.h>
#include <string>

template <class T>
class MainGlobaler
{
public:
MainGlobaler(char *) {puts("Main globaler constructor");}
virtual ~MainGlobaler() {puts("Main globaler destructor");fflush(stdout);}
};

int main(int argc, char **argv)
{
MainGlobaler<std::string> MgArr[] =
{
MainGlobaler<std::string>("Klava"), MainGlobaler<std::string>("Slava")
};

puts("Top of main");
return 0;
}
[ks@const:~]% ./aaa
Main globaler constructor
Main globaler constructor
Top of main
[ks@const:~]% g++ -v
Reading specs from /usr/lib/gcc/i586-mandrake-linux-gnu/3.4.3/specs
Mandriva 2005

Здравствуйте, ilejn,

Сдается мне что, вы что то утаили? хотя бы где #includes <string>?

Могу ошибатся, но мне кажется что такое поведение вполне обправдано,
на такие мысли натолкнуло прочтение 12.4 сноска 10, на ум пришли
следующие пути решения:

static MainGlobaler<std::string> MgArr[2] =

Или необходимо инстанционирование шаблона до объявления MgArr, например:

MainGlobaler<std::string> dummy("zhopa"); // до обявления MgArr

int fake = sizeof(MainGlobaler<std::string>); // до обявления MgArr

Если я не прав, поясните в чем?

Здравствуйте, megawatt, Вы писали:

M>Здравствуйте, ilejn,

M>Сдается мне что, вы что то утаили?

Нет, ничего не утаил.

M>хотя бы где #includes <string>?

В iostream.

M>Могу ошибатся, но мне кажется что такое поведение вполне обправдано,
M>на такие мысли натолкнуло прочтение 12.4 сноска 10,

==
Destructors are invoked implicitly (1) for a constructed object with static storage duration (3.7.1) at program
termination (3.6.3), (2) for a constructed object with automatic storage duration (3.7.2) when the
block in which the object is created exits (6.7), (3) for a constructed temporary object when the lifetime of
the temporary object ends (12.2), (4) for a constructed object allocated by a new-expression (5.3.4), through
use of a delete-expression (5.3.5), (5) in several situations due to the handling of exceptions (15.3). A program
is ill-formed if an object of class type or array thereof is declared and the destructor for the class is not
accessible at the point of the declaration. Destructors can also be invoked explicitly.
==

Меня не наталкивает. Соответственно, буду признателен за пояснения.

M>на ум пришли следующие пути решения:


M>

M>static MainGlobaler<std::string> MgArr[2] =
M>

Такой метод я уже придумал, но его суть мне непонятна.

M>Или необходимо инстанционирование шаблона до объявления MgArr, например:

M>

M>MainGlobaler<std::string> dummy("zhopa"); // до обявления MgArr
M>

M>

M>int fake = sizeof(MainGlobaler<std::string>); // до обявления MgArr
M>

Отлично. Спасибо.

M>Если я не прав, поясните в чем?

Вы, похоже, правы во всем, и я очень признателен за предложенные решения. Отдельно буду признателен, если Вы поясните, каким образом написанное в [class.dtor] связано именно с массивом именно неопределенной длины именно шаблонных классов, потому что я этого постичь не могу.