Массивы против контейнеров

[BRE]

Странные рассуждения. Мне тоже иногда приходится писать свои велосипеды. Бывают проблемы, которые принципиально не решаемы с помощью стандартных вещей.

А я где то писал, что изобретать велосипеды плохо? 
Я говорил о том, что есть базовые структуры хранения данных, у которых есть свои плюсы и минусы и не существует структуры, лишенной всех недостатков - которую и ищет Igors.
Всегда (как при реализации своего велосипеда, так и при выборе стандартного контейнер) мы вынуждены выбирать: "память против скорости", "доступ против памяти", ...

[Igors]

С твоими требованиями, самое простое, это придумать свою структуру хранения данных, лишенную всяческих недостатков.  Этакий IdealContainer. 

Тебе с одной стороны хочется что бы памяти много не кушал, с другой стороны, что бы доступ был быстрым, а вставка/удаление выполнялось бы за O(1)....

Ну а пока весь реальный мир ждет этого чуда, он вынужден идти на компромиссы и все время делать выбор чем сейчас пожертвовать, что бы получить какое-то более важное в данном месте свойство.
 

Ну вот, опять задачка не понравилась - видите ли, требования у меня завышенные. Уж и не знаю как угодить   А ведь там несложно и решений не одно. Ладно, вот еще случай (классический).

Есть такая структурка

Код

C++ (Qt)
struct Vertex {
 QVector3D mPosition;   
 QVector3D mNormal;    
 QVector3D mTexture;   
 QVector3D mBlur;   
 ARGB mColor;
 ..
};
 

Дело в том что mPosition есть всегда и всегда значима. А вот все остальное может быть - а может и не быть в любых вариациях. Напр. mTexture может иметься а mColor нет, или наоборот - как фишка ляжет. Варианты:

1) Держать всегда все данные (как определена структура выше). Это конечно очень просто и это будет работать. Но признавать свою беспомощность не хочется

2) Разделить все на отдельные контейнеры (mPosition в одном, mNormal в др. и.т.д). Это ведет к заметному усложнению др. частей кода - я везде буду обязан работать только "по индексу" а не "по указателю". Это не очень приятно.

3) Ваше решение ?

Заметим что на "чистом С" решение довольно просто. А как это решить на ++ (которое вроде круче) ?

Спасибо

[Igors]

Бывают проблемы, которые принципиально не решаемы с помощью стандартных вещей.

На мой взгляд "принципиально не решаемы" бывает очень редко. А вот когда стандартное решение есть, но не устраивает - частенько

[BRE]

Ну вот, опять задачка не понравилась - видите ли, требования у меня завышенные. Уж и не знаю как угодить  А ведь там несложно и решений не одно. Ладно, вот еще случай (классический).

А это не задачка, это требование типа "хочу что-бы все было зашибись само и сейчас". 
Да и угождать мне не надо, особенно "своими задачками".

А как это решить на ++ ?

В лоб:

Код

C++ (Qt)
struct Vertex
{
 QVector3D mPosition;   
 QVector3D *mNormal;    
 QVector3D *mTexture;   
 QVector3D *mBlur;   
 ARGB *mColor;
 ..
};
 

Чуть подумав:

Код

C++ (Qt)
class Vertex
{
public:
 void addProperty( ... );
 void removeProperty( ... );
 
private:
 QVector3D mPosition;
 QList<Propertiy> mProperties;
};
 

Ну и хочеться уже взглянуть на что-то из этого: 

В некоторых случаях мне приходится управлять данными "без контейнеров", в стиле С. Да, это требует заметно больше усилий и аккуратности. Зато получается намного чище, код быстрее а иногда.. даже текст короче

Заметим что на "чистом С" решение довольно просто.

Так сказать хочется увидеть твой кунг-фу "чистый С". В свое время я был большим ценителем, да и сейчас люблю насладится красотой хорошего кода.

которое вроде круче ?

Детский сад. 

[Igors]

В лоб:

Код

C++ (Qt)
struct Vertex
{
 QVector3D mPosition;   
 QVector3D *mNormal;    
 QVector3D *mTexture;   
 QVector3D *mBlur;   
 ARGB *mColor;
 ..
};
 

Давайте посчитаем байты

sizeof(QVector3D) = 12  (3 float)
sizeof(ARGB) = 4 (по байту на канал)

С использованием указателей каждый член весит уже 20 байт (32 бит) или 24 (64 бит). Немного сэкономили "когда данных мало", зато раздули почти вдвое "когда есть". Итого: памяти съедается не меньше "зато" добавили забот с указателями.

Так сказать хочется увидеть твой кунг-фу "чистый С". В свое время я был большим ценителем, да и сейчас люблю насладится красотой хорошего кода.

Конечно покажу - но когда Вы перестанете злиться (понимая что Вы не правы  )

[BRE]

Итого: памяти съедается не меньше "зато" добавили забот с указателями.

А почему для комментирования было выбрано решение "в лоб"? 

Конечно покажу - но когда Вы перестанете злиться (понимая что Вы не правы  )

Я совершенно не злюсь. 
Хотя надежда увидеть код почти покинула меня. И мне все больше кажется, что тот абзац из первого сообщения этой темы, обычный треп или попытка произвести на кого-то впечатление. Да? 

[Igors]

А почему для комментирования было выбрано решение "в лоб"? 

Ну так Ваше "не в лоб" (чуть подумав) еще хуже по всем статьям 

Я совершенно не злюсь. 
Хотя надежда увидеть код почти покинула меня. И мне все больше кажется, что тот абзац из первого сообщения этой темы, обычный треп или попытка произвести на кого-то впечатление. Да? 

Та оно мне надо? Ну произведу я на Вас впечатление, и что я с этого буду иметь? 
Просто не люблю когда книжка выдается за свои мысли/убеждения. Я уважаю знания, но считаю что их надо не только "прочитать", но и осмыслить, пережить, пропустить через свой опыт. Я решал эту проблему так, мне интересно как бы ее решали др. программисты. Если они считают что здесь проблемы нет и можно обойтись "ширпотребом" - здесь я с ними не соглашусь, т.к. у меня эта проблема есть. Но навязывать свое мнение не буду.

По поводу реализации - здесь никакой "интриги" нет. Ну предположим каждый вертекс может иметь свой расклад.

Код

C++ (Qt)
struct Vertex {
 size_t GetSize( void )  const { return theGlobalVertexTable[mTableIndex].GetSize(); } 
 
// ой как бы здесь заверещала наша малышь  :)
 Vector3D * GetNormal( void )  { return theGlobalVertexTable[mTableIndex].GetNormal((char *) this); } 
 ,,,
 
// data
 Vector3D mPosition;   // постоянные данные
 UInt32 mTableIndex;   // индекс расклада в таблице
};
 
struct VertexTableEntry {
 size_t GetSize( void ) const { return mSize; }
 Vector3D * GetNormal( char * src )  { return (Vector3D *) (mNormalOffset ? (src + mNormalOffset) : NULL);  } 
...
 
// data
 size_t  mSize;
 size_t mNormalOffset;
 ...
};
 

Подробности очевидны. На практике не бывает "все вертексы уникальны" - они объединяются в группы с одинаковыми раскладами. Но суть та же, ну просто подаем tableIndex как параметр (вместо члена класса). Правда никакой стандартный контейнер не прокатит (нет реального sizeof), но это наименьшая из всех проблем. Все просто если не цепляться за догмы/стереотипы 
 

[BRE]

Ну так Ваше "не в лоб" (чуть подумав) еще хуже по всем статьям 

А ты попробуй подумать сильнее. 
Скажем замени QList на другой контейнер (не стандартный, но очень простой), который позволит минимизировать расход памяти на хранение свойств.

Ну а пример... это пять.