Добавям код към готов МФЦ VC++ проект, проблема е следния:
трябва да използвам обект CPtrArray, но след като го декларирам в добавения код
гърми един ASSERT_VALID(this) след пускане и в дебъг единствено работи, ако този CPtrArray e деклариран в един от другите файлове, който си идва с проекта, а в моя файл е обявен като extern. Как да може да се оправи това? Благодаря предварително.

значи на 6тицата забелязах един бъг - ако някъде имаш декларирана глобална променлива, а по-долу extern декларация на същата, то конструктора и се вика два пъти върху една и съща памет. мирише ми на това, виж дали нямаш екстерн декларация под мястото където правиш твоята.

Нещо не съм дал пълна информация - проблема се явява когато извикам някой метод на класа например Add или SetSize, в дебъгера го проследявам и виждам че се дъни на Asserta където се провярява дали this e валидно, самия указател изглежда си е наред, но има една проверка за VTable pointer който o e NULL и там гърми. Ако го компилирам с изход релеасе същия код си работи(то нали не се вика ассерта).

то нищо не си дал - така че как да ти се помогне !?

zaphod ти е дал joker - макар че неговото твърдение че това (горе) е бъг на VC - не е вярно.

пример:

int ququ = 5;

в друг файл:
extern int ququ = 3;

резултата е 2 променливи ququ едната е 5 а другата 3 (за съответния фалй, видимост, ...)
само линкера се оплаква (warning) че има дублирани променливи

ако се декларира (правилно)
extern int ququ;

всичко е както се очаква!

ако искаш да ти помогнат - пусни част от кода

Ок, първо да уточня по ясно че проблема не е при компилиране или линкване,програмата се билдва с 0 error(s), 0 warning(s) и в двата случая, но ето по конкретно:

[u]Случай 1:[/u]

file1.cpp:
#include "stdafx.h"
#include ....
.....

file2.cpp:
#include "stdafx.h"
#include ....

CPtrArray SomeArray;
....
void AddPtr(LPVOID Ptr) {
SomeArray.Add(Ptr); // при изход дебъг ASSERT_VALID(this) ,който се вика във Add не минава, дъни се при някаква проверка за VTable pointer
}

[u]Случай 2:[/u]

file1.cpp:
#include "stdafx.h"
#include ....
CPtrArray SomeArray;
....

file2.cpp:
#include "stdafx.h"
#include ....

extern CPtrArray SomeArray;

void AddPtr(LPVOID Ptr) {
SomeArray.Add(Ptr); // няма проблем при изход дебъг
}

аз говорих за друг случай - една променлива на която конструктора се вика два пъти, а не две променливи.
но и това за което говориш, ако е вярно пак бих го окачествил като бъг или нередност, понеже не виждам никакви основания да прави две променливи. правилата са ясни, едно име - една променлива.

ами то "int ququ=0;" - си е конструктор за "клас" int

казвам че не е бъг защото аз ползвам BCB10 - и там е същото като в VC!

оффф....случай сега, повтарям за последно, ако и сега не го разбереш не мога да ти помогна повече.
ако напишеш
CString s;
extern CString s;
конструктора на s ще се извика ДВА пъти върху една и съща памет. програмирането не е литература и ако ще ми обясняваш че и=3 било конструктор то ти препоръчвам да станеш даскал по литература. първо че оператора = НЕ Е конструктор, и второ и да беше пак говорим за съвсем различни неща.

@diofan след допълнителната информация че асерта гърми по нулиран VFT указател, мога да кажа че това не е случая за който говорим. два пъти изпълнен конструктор не може да нулира поинтера. сега обаче ще ти кажа как да гепнеш проблема - студиото има една функция, слагане на точка на прекъсване върху памет. сложи го върху адреса на тази променлива, с обхват 4 байта. пусни програмата, точката ще се активира един път при създаването на обекта. втората активация вече ще е тази която ти трие паметта.

понеже си ми "любимец" ще си направя труда да тЪ светна:

int ququ=5;
extern int ququ=3;

е абсолютно идентичен случай на:
CString s;
extern CString s;

и в двата случая имаш дублирани имена (линкера на BCB10 дава warning) - ако е "примитивна" променлива се инициализира 2-та пъти, ако е клас - му се вика конструктора 2 пъти !

не е бъг - защото и VC & BCB го позволяват !
аз лично бих предпочел да ми дава грешка ако в extern инициализирам ... - щото я допусках (на младини!) доста често ...

до тука бях