Ты память криво читать будешь, поедположительно из соседних элементов. А на последнем получишь скорее всего краш
Я бы в твоем случае сделал бы массив указателей, работая с элементами массива приводил бы к нужному классу.
Да, так вполне должно работать.
Другой вопрос - а зачем ты заводил массив типа CParticle, а не CParticleAur?
Он где-то обходится в родительском классе? Тогда ты получишь ошибку в нём, из-за того, что он будет обходиться как массив CParticle с совершенно другим размером элемента.
XaeroX почему же? Краш получен. Прям таки клубничный. Потому что CParticle намного меньше CParticleAur.
Проблема в том, что аллокатор и хранилище - внутри CParticleSystem - базового класса всех ПС (их много, очень много). И тащить свойства CParticleAur внутрь CParticle - это нарываться на падение производительности и перерасход памяти.
Вощем, я и сам подумывал над массивом указателей, но уж очень не хочется переписывать методы обращения в... 9 системах. :-/ По нескольку в каждой. Потом отлаживать, искать опечатки... Или накручивать абстракцию типа GetParticle(i), получая по распухшему стеку...
XaeroX, краш как раз очень даже возможен везде кроме первого элемента массива (по ясным причинам).
При таком преобразовании выкладка массива (обращение по элементам) становится невалидной. А так как указатель на таблицу виртуальных функций являются частью объекта, при таком раскладе происходит обращение по "мусорному" адресу и попытка найти там адрес нужной функции и выполнить её код.
~ X ~:
Я так понимаю ты хочешь обойти краш, который возникает из-за обращения к CParticle []?
Можешь использовать функцию для получения элемента массива
C++ Source Code:
1
CParticle* getCParticle(CParticle* particleList, int stride, int id)
Ну или перегрузить оператор [] для CParticle по аналогии. Должно работать. Если тебе не хочется переписывать под массив указателей. Но вряд ли это можно назвать лучшем способом (:
P.S. XaeroX прав: краша в том коде, который ты показывал быть не могло.
ComradeAndrew я об этом уже говорил. Про гетпартикл. Но это уже ужос какой-то. А STL использовать ну никак не хочется.
Вобщем, думаю.
Наверное, всё-таки, придётся писать обёртку типа:
C++ Source Code:
1
// Creation 1:
2
fot (i=0;i<n;++i)
3
m_pParticleList[i] = new CWhateverParticle;// non-contiguous segments: BAD
4
5
// Creation 2:
6
CWhateverParticle *pContainer = new CWhateverParticle[n];// contiguous array
7
fot (i=0;i<n;++i)
8
m_pParticleList[i] = &pContainer[i];
9
10
// Usage:
11
m_pParticleList[i]->KillSomePigeons();
12
13
// Destruction 1:
14
fot (i=0;i<n;++i)
15
delete m_pParticleList[i];
16
17
// Destruction 2:
18
fot (i=0;i<n;++i)
19
m_pParticleList[i] = NULL;
20
21
delete *pContainer;
22
// or
23
delete [] m_pParticleList[0];// ???
Только вот с деаллокацией как-то сомнительно. Во втором варианте лучше бы запомнить контейнер.
Кроме того, трюк с выделением непрерывного массива не обязан гарантировать скорость обращения по указателям т.к. есть мнение, что компилятор И процессор могут оптимизировать , но не переходы по указателям...
[CPP] this << F1 // OOP: субклассы в массивах
| IP: 
27-08-2014 08:42
