Нужен способ помещения разного рода типа данных в контейнеры типа массивов или структур

Сабж. Нужен способ помещения разного рода типа данных в контейнеры типа массивов или структур или... пободного рода простых для восприятия методов.
Поясню.
Пишу базу дынных, используя структуры я могу получить динамически кол-во строк исходя из данных в структуре.
Например:
Т.е. При использовании такого вида структуры, я могу создать N-ое кол-во строк динамически с помощью оператора New.
Но вот кол-во членов не может быть динамическим на сколько я знаю, т.е. нельзя в структуре написать: m[n][j]
Где заранее будет проинициализированна глобальная переменная типа int, а перед определением самой структуры, я бы написал что например n = 10, j = 30...
Ещё интересует вопрос с разнородными переменными, например я вот захочу чтоб в структуре было char[], int, float, WORD типы переменных... Посоветовали юзать тип VARIANT, однако как его юзать, если кол-во бит выделенное для каждого типа переменных - будет различаться...
В общем нужен простой подход(в синтаксисе) к данному вопросу.
И повторюсь - классы и векторы не предлагать, они слишком сложны в синтаксисе.(переубеждать меня не надо, данная тема не для этого создана).

0

DrOffset, список сложен в синтаксисе(покрайней мере из того что я видел, очень много сторонних разделительных символов). Удаляться тоже будут. Но это же не проблема в случае с массивом структур. Да ссылочку пожалуйста, я так понимаю устав форума не разрешает публично выкладывать ссылки с сторонних сайтов, поэтому в приват если можно. Ну а для зрелищности можете закопипастить кусочек интересующего кода =)
Да и раз вы тут новенький(в смысле в моём топике), поясню, что в результате мне нужен полноценный контейнер с хранилищем разнородной информации. Если список даст мне возможность реализовать - то может и попробую, но опять же тут будет соотношение сложность синтаксиса\исполняемость конечной задачи.

0

Сообщение от Izual список сложен в синтаксисе

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

Сообщение от Izual в результате мне нужен полноценный контейнер с хранилищем разнородной информации

Это вы сами напишете, на основе массива, или списка - это вам решать. Или может быть вас все-таки кто-то уговорит на использование готового (напр. того же VARIANT в списке или массиве). Я подскажу - VARIANT использует union для организации совместного хранения разнородных данных.

Сообщение от Izual соотношение сложность синтаксиса\исполняемость конечной задачи.

Задача, как я понял, у вас изначально непростая. Следовательно решать ее простыми способами можно и нужно, но главное - чтобы не примитивными. И выбор структуры данных это не тот уровень сложности, которого стоит опасаться. Будут у вас гораздо более трудоемкие моменты.

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

Вложения

c_list_test.7z (1.9 Кб, 35 просмотров)

0

DrOffset, спасибочки, заценю.

реализация в массиве удаления из середины

Очень просто, алгоритмы - моя страсть. Обожаю такие задачки, а для удобства уже универсальную функцию себе сделал.(естественно с освобождением памяти, хотя пока что утечку памяти не контролю, хотя надо бы начать, а то уже было, нечаянно даже из за этого дюпнул шмотку на офф серве diablo2^^)

VARIANT использует union

Да да, вот почему и возник на 4 странице вопрос о битах, т.к. в книге совместно с union ещё были примеры с unsigned, типа можно тип менять. Хотя написано что массив символов нельзя использовать, потому что unsigned поле не имеет "определённого адреса"... Не очень понимаю))
И да, меня убеждать использовать VARIANT не надо, я как бы к этому и иду, только вот на "чистом" Си не нашёл примеров... все как на подбор только через омг синтаксис классов и векторов. Вот от поиска и недостатка инфы конешно крыша едет... хочется бросить всё, но разум говорит что не надо, ибо идея стоящяя.(хотя вот почему и подумал о простом массиве символов - потому как из него конвертировать можно во что угодно, алгоритмы в принципе просты, да и есть даже некоторые стандартные функции)

решать ее простыми способами можно и нужно, но главное - чтобы не примитивными

А в чём разница? Примитив это как два колеса, но только их отношение даёт результат.

выбор структуры данных

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

Добавлено через 15 минут
Так ну, вот списки... посмотрел, очень не удобно и не понятно! Сам по себе синтаксис списков - требует знания работы со списками. В структурах и массивах такого нет. Так же замечу, постоянно встречающийся символ '->' стрелочки: не очень хороший вариант, я всё же делаю подобие лего - где все детали ясны и понятны.
Кстати по поводу "примитива" вспомнился фильм 2008 года "Проблеск гениальности", где мужик изобрёл из простейших составляющих: резитор, транзистор и конденсатор. Т.е. только базовыми приборами человек создал то, чего ещё не было - в контексте фильма: прерывистые дворники.

0

Сообщение от DrOffset Сложность понятие относительное

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

Сообщение от Izual А в чём разница?

Примитив - это набор инструментов и материал для создания колеса. Зачем создавать новые колёса, если уже имеются в наличии все нужные?

Сообщение от Izual Сам по себе синтаксис списков - требует знания работы со списками. В структурах и массивах такого нет.

Синтаксис структур и массивов не требует знания работы со структурами и массивами?

0

Сообщение от Izual посмотрел, очень не удобно и не понятно!

Это страх говорит в вас
Код мог бы быть проще, будь он написан с использованием так не любимых вами классов, но это не важно.
Потому что выигрывая в простоте в одном месте, мы получаем увеличение сложности в другом. Вот даже тот пример, я отказался от классов, отказался от С++ как от более продвинутого инструмента описания задачи. Увеличилась ли сложность? Конечно. Ведь теперь очень много вещей, которые в С++ решались на уровне языка автоматически, приходится делать вручную. Однако появилась и простота, простота управления структурой данных, теперь можно управлять ей на самом элементарном уровне, как мне угодно. Вот вам статья на эту тему.

Сообщение от Izual постоянно встречающийся символ '->' стрелочки: не очень хороший вариант

Рулить динамическим массивом и элементами в нем без нее тоже не получится. Один из базовых механизмов роботы с памятью в С и С++ - это указатель, заметьте, базовых, то есть - это и есть как раз тот транзистор, про который вы говорили.

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

0

elivin, идите троллить в другое место. Если вы чего то не понимаете, это не значит что оно не правильно, это может так же означать что вы недоразвиты. А что бы понятнее фраза была, вот вам лично ещё: "Возраст ещё не говорит о наличии мудрости".

DrOffset, дело не в страхе, я же сказал нужно как можно проще.
Я уже создал программу типа базы данных, год делал и до сих пор улучшаю. До сих пор не пользовался никакими стрелочками... Отсюда вполне логичный вопрос о том что их можно избежать.

не любимых вами классов, но это не важно.

Концепция - нужно читабиельность кода свести к минимуму, потому это важно, потому что они усложняют понимание. Уже писал 100 раз...
Статейку гляну, такие вещи как раз таки требуются(хотя до уровня ассеблера доходить не желаю).

Один из базовых механизмов роботы

Возможно его можно избежать, как в прочем я с ним не сталкивался пока программу делал.

изменения взглядов и подходов к задаче

В том то и дело, что нагромождать новомодными фичами я не собираюсь программы. Взгляды надо менять на то что было в старом Си и как это использовать по новому.
Слышали наверно про "запланированное устраревание"? - именно поэтому не хочу идти "в ногу со временем", т.к. если идти - создаёш временное, а не вечное.

0

Сообщение от Izual Слышали наверно про "запланированное устраревание"?

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

PS. Больше тут писать не буду. Можно вернуться к этому вопросу через год, когда можно будет оценивать пройденный путь и вопросы с которыми вы столкнулись в разработке. Вот тогда это будет интересный разговор.

0

DrOffset, естественное не каснётся базовых алгоритмических операций и вызовов объектов. Именно это стоит верхом того что может быть с минимальной вероятностью быть исключено(изменено).

В принципе теперь тема осталась только с размещением разнородного типа данных, например VARIANT, но с использованием минимально энергоёмких символьных операций(за исключением ест. стандартных, типа логических и т.д.).

0