[b]создание объекта статически / большой список аргументов

[sunjob]

создание объекта статически / большой список аргументов конструктора

добрый день

хочу подрихтовать "некую" библиотеку, содержащую "некий" класс
конструктор должен получить "порядочный" список параметров, т.е. обычными 3я тут не обойтись

как решение вижу пока след:
- передавать конструктору указатель на структуру с инициализирующими параметрами
или
- создавать "общий" конструктор, а затем "методами" добивать/дозаполнять параметры

2й способ, по понятным причинам мне не нравиться (коряво, неудобно, итд итп)

в первом способе есть так же некие "не-айс моменты"
- сначало статически создается структура
- заполняется параметрами
- отправляется в конструктор
- и повтор для след. экз. класса
- а... после создания всех экземпляров класса, сама по себе структура не уничтожается, продолжает болтаться в памяти, в случае с 8bit-AVR контролллерами, и, учитывая, что "инициализация нужна только в самом начале", потом - только "работа" - это становится более чем "не айс"...

хочу оптимизировать, что бы не было лишних обьектов.
о динамическом создании/class/operator "new/delete" - в курсе (считаю, что созадвать и потом удалять структуру тоже "корявое решение")

вопрос
можно ли создавать обьекты класса "статически" с уже инициированными полями? (типа, как описание структуры и потом создание экземпляра структуры с инициализацией - в "кривых скобках" через запятую)
возможно решение есть и с "динамическим" созданием

с/си++

(возможно, "много чего не рублю", корректируйте... можно "ключевыми словами", ссылками)

спасибо

[ARV]

в AVR любая константа, которую вы пишите в коде, так или иначе занимает flash - хоть в коде, когда заносится в регистры, хоть просто во flash, когда заносится в ОЗУ. то есть как вы ни крутите, объем кода вы не измените, если требуется несколько разных констант.

то есть я клоню к тому, чтобы конструктор вашего класса получал указатель на структуру не в ОЗУ, а во flash... так вы займете ОЗУ ровно столько, сколько потребно для всех ваших экземпляров класса, и при этом никак не увеличите занятую flash больше, чем необходимо...

[mrFox]

можно сделать инициализированную структуру во флэш
у еще лучше, если структура 1 к 1 будет совпадать с данными класса - тогда данные переливаются одной memcpy_P

[ptr128]

- сначало статически создается структура
- заполняется параметрами
- отправляется в конструктор
- и повтор для след. экз. класса

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

[sunjob]

вопрос был таким: можно ли создавать обьекты класса "статически" с уже инициированными полями?
за ответы спасибо

[Аlex]

с уже инициированными полями?

Полями чего, класса ? Можно. И даже не передавая ничего в конструктор.
Хотя, никто не мешает делать инициализацию в самом конструкторе.

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

[sunjob]

вопрос
можно ли создавать обьекты класса "статически" с уже инициированными полями? (типа, как описание структуры и потом создание экземпляра структуры с инициализацией - в "кривых скобках" через запятую)

//
// создание элемента структуры "статически" с уже инициированными полями
//
typedef struct XStruct
{
int a;
int b;
int c;
// blah-blah-blah
};

XStruct x = {1,2,3};

учитывая, что в "плюсах" - struct рассматривается как класс с public полями, то соотв. появился вопрос об подобном создании элемента класса со "статической" инициализацией полей ...

как уже писал, да, можно понавпихивать методов для заполнения, но, блиииннн... учитывая ограниченность рессурсов и, тем более, что вся эта ХРЕНЬ нужна только в самом начале, А в основной работе - не будет использоваться ... ТО это не кашегнинько как-то ... :о)

понятно, что public - решает "всеобщий доступ"... но это тоже не гут

переходя к классу, хотелось бы (виделось так :о)

class XStruct
{
// констурыктыры и дизтрыктыры...и пр...
private:
int a;
int b;
int c;
// blah-blah-blah
};

XStruct x = {1,2,3};
XStruct *p = new XStruct() {1,2,3};

естественно, такая форма конструктора "не катит" (конструктор/диструктор оставил без описания по понятным причинам, либо "default", либо я еще НЕ ЗНАЮ ЭТОЙ НОВОЙ ФОРМЫ ОПИСАНИЯ... если она есть)

итак, как можно инициализировать поля? кот обещал, кот выкопает и поделиться? :о)


назовите условия - в GPL пользование :о)

p.s.
естественно, разговор идет об AVR/Arduino версии языка а не об C++11

...

как то так (все имхо), спасибо

[ptr128]

вопрос
можно ли создавать обьекты класса "статически" с уже инициированными полями? (типа, как описание структуры и потом создание экземпляра структуры с инициализацией - в "кривых скобках" через запятую)

//
// создание элемента структуры "статически" с уже инициированными полями
//
typedef struct XStruct
{
int a;
int b;
int c;
// blah-blah-blah
};

XStruct x = {1,2,3};

А с чего Вы решили, что в Гарвардской архитектуре это будет "статическая" структура с уже инициализированными полями? Когда Вы загружаете прошивку, прошивается только флеш. В частных случаях можно прошить еще EEPROM. А вот RAM в любом случае будет не инициализирована. В Вашем случае, GCC сформирует код, который при старте программы будет выполнять копирование значений 1, 2 и 3 из флеша в оперативку.

Единственный способ разместить данные с уже инициализированными значениями, это спецификация PROGMEM. Вот так:

Код: Выделить всё

#include <avr/pgmspace.h>

typedef struct XStruct_st
{
int a;
int b;
int c;
// blah-blah-blah
} XStruct_t;

XStruct_t x PROGMEM = {1,2,3};

Но только в этом случае напрямую Вы уже к своей структуре не обратитесь. Только через макрос pgm_read_byte() или специальные функции для работы с программной памятью, типа strcpy_P() или strcpy_PF(). То есть, реализация такого класса прозрачно, с перегрузкой всех операций, еще тот гимморой. В итоге, и оперативку не с экономите, и размер кода увеличите.

[sunjob]

А с чего я решил... - многозначительненькое такое начало :о)

about PROGMEM - со всеми вытекающими ОСОБЕННОСТИЯМИ в курсе...

возможно не совсем коректно описал задачу

нужно при создании экземпляра класса "умудриться" инициализировать внутр. поля (дост. большой список) без лишних телодвижений, обьемов кода и ФЫСЁ!!! :о)

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

как то так...

[ptr128]

Если Вы создаете объект, то этот объект уже, по определению, динамический. Максимум, он может содержать указатели на статические объекты. Но память под эти указатели все равно будет выделена динамически и инициализировать их иначе, чем кодом, Вам все равно не удастся.
Для минимизации кода, можно все Ваши поля объединить в одну структуру и инициализировать ее в конструкторе при помощи memcpy_P()/memcpy_PF() из такой же структуры, но в флеш. Без кода динамическую память (объект создаваемый new) Вы не проинициализируете.

[sunjob]

ну да, примерно так и думал... :о)
по поводу "статическОГО" - слово специально в ковычки взял
спасибки

[Аlex]

переходя к классу, хотелось бы (виделось так :о)

class XStruct
{
// констурыктыры и дизтрыктыры...и пр...
private:
int a;
int b;
int c;
// blah-blah-blah
};

XStruct x = {1,2,3};
XStruct *p = new XStruct() {1,2,3};

Хм.. интересно... Про конструкторы знаем, а про передачу в него параметров - нет ? Странно

Код: Выделить всё

class XStruct
{
public:

XStruct(int _a, int _b, int _c): a(_a), b(_b), c(_c) {};  // Именно в таком виде, значения в "a", "b", "c" будут копироваться при выделении памяти экземпляру. Можно инициализировать даже константы

private:
int a;
int b;
int c;
// blah-blah-blah
};


//....................
//....................

XStruct x(1,2,3);
XStruct *p = new XStruct(1,2,3);

//....................
//....................

Или я что-то опять не понял ?

[sunjob]

я, видимо, не уточнил, что праметров много, и все их перекидывать через конструктор, посчитал - не айс...
ну, т.е. при изучении старых-добрых книг по обычному си/++ указывалось что желательно использовать не более 3х параметров для передачи в функцию (уже не помню, какие то ограничения на стек/регистры) в противном случае передача происходит не оптимальным образом, для AVR судя по всему, эти ограничения еще ужее :о)

ну вот как то так, может все не так и плохо
саму задачу по передаче вроде как "изыскал решение", но решил поинтересоваться, может есть какие "выкрутасы/хитрушки" по "большой инициализации"

мур...

[ARV]

вам уже давно я советовал вашу большую инициализацию сделать через структуры/массивы во flash - что еще надо? все равно более оптимального способа для AVR вы не найдете!

в конструктор передаете адрес структуры во flash, которая содержит все нужные параметры, хоть сотню. в методах класса тупо добываете эти данные путем обращения к pgm_read_xxx по этому самому указателю со смещением. причем считываете эти данные не в локальную структуру экземпляра класса, а в момент востребования, чтобы не занимать напрасно ОЗУ, которого всегда мало.

так как все экземпляры класса у вас будут статическими, в итоге получится наиоптимальнейший код по всем статьям. какие еще изыски вам потребны?

[Аlex]

Ну да, самый оптимальный вариант - хранить в классе указатель на данные.
Только вот инициализировать данные, указатель на который будете передавать, всё равно придётся

[ARV]

инициализировать данные, указатель на который будете передавать, всё равно придётся

ну так это очевидно!

Код: Выделить всё

constructor(10, 20, 30, 40, 50);

ничем не отличается от

Код: Выделить всё

struct{
   int a1, b1, c1, d1, e1;
} var = {10,20,30,40,50};
constructor(&var);

но в случае размещения структуры в flash-памяти это не приведет к удвоению расходов (ОЗУ + код)

[Аlex]

но в случае размещения структуры в flash-памяти это не приведет к удвоению расходов (ОЗУ + код)

Однозначно и бесспорно !

ARV, я не опровергаю Ваши посты, а дополняю их И про "всё равно придётся инить данные" я говорил в сторону ТС'а

[ARV]

я не опровергаю Ваши посты, а дополняю их

ну так и я как бы конкретизирую ваши

[sunjob]

> about PROGMEM - со всеми вытекающими ОСОБЕННОСТИЯМИ в курсе...

[ARV]

about PROGMEM - со всеми вытекающими ОСОБЕННОСТИЯМИ в курсе...

вот это сейчас что было? грязные намеки или вопль о помощи?

не знаю, у кого что там вытекает, но даже с pgm_read_xxxx предложенная мной концепция проявила бы себя отлично, а если учесть, что AVR-GCC последних версий (и в том числе Atmel Toolchain) поддерживает flash на уровне компилятора (т.е. не требуются особые функции для чтения данных, но поддерживаются на "нативном" уровне указатели на flash и т.п. фишки), то и подавно.