функция malloc

[_Bers]

Сообщение от netrino

В данном конкретном случае проблемы будут на 64-битных машинах и в принципе на любых компиляторах, где размер int отличается от размера машинного слова (по нему выравниваются значения в стеке). Единственный портабельный способ гулять по чужому стеку - va_list/va_start/va_arg/va_end, так работают vprintf и друзья.

Переменное кол-во значений обязательно? Было бы лучше поискать альтернативные решения (например просто определить Bar как ф-цию, которая принимает указатели или ссылки), потому как любой из способов для плюсов будет не типо-безопасным (разве только шаблоны переменной длины из C++11).

ААа... выравнивание.. значит.

А типобезопасность присутствует. При помощи тех же шаблонов, правда не variardic.


Вот такой подход учитывает выравнивание?

struct STest{ int a1; char a2; };

void Bar(void* ptr)
{
    STest* test = (STest*)ptr;
    cout<<"a1 = " <<(*test).a1<<endl;
    cout<<"a2 = " <<(*test).a2<<endl;
}

void Foo(int a1, int a2)
{
    Bar(&a1);
}

int main()
{
    Foo(10,'a');
      return 0;
}

[netrino]

Сообщение от _Bers

ААа... выравнивание.. значит.

А типобезопасность присутствует. При помощи тех же шаблонов, правда не variardic.


Вот такой подход учитывает выравнивание?

struct STest{ int a1; char a2; };

void Bar(void* ptr)
{
    STest* test = (STest*)ptr;
    cout<<"a1 = " <<(*test).a1<<endl;
    cout<<"a2 = " <<(*test).a2<<endl;
}

void Foo(int a1, int a2)
{
    Bar(&a1);
}

int main()
{
    Foo(10,'a');
      return 0;
}

Нет, такой тоже не подходит. Каждое значение в стеке выравнивается по размеру машинного слова (4 байта для 32х-битных архитектур, 8 для 64х-битных). В Вашем же случае, выравнивание будет по int (которое 4 байта на обоих архитектурах в основных реализациях). То есть при попытке доступа подобным образом к полям структуры, поле a2 не будет доступно на 64х-битных архитектурах.

          a1                   a2
stack: [_|_|_|_| _|_|_|_] [_|_|_|_|_|_|_|_]
          a1      a2
STest: [_|_|_|_][_|_|_|_]

Для верного итерирования по стеку нужно использовать типы, равные машинному слову, например size_t или ptridiff_t. Но и здесь всё равно нет гарантии корректности, всё же, если хочется работать с указателем на стэк, то используйте средства cstdarg.

[Пепел Феникса]

а вы учли передачу не через стек?

[_Bers]

Сообщение от netrino

Нет, такой тоже не подходит. Каждое значение в стеке выравнивается по размеру машинного слова (4 байта для 32х-битных архитектур, 8 для 64х-битных). В Вашем же случае, выравнивание будет по int (которое 4 байта на обоих архитектурах в основных реализациях).

Получается, что выравнивание данных на стеке, и выравнивание данных в полях структур выполняется разными способами?

[netrino]

Сообщение от _Bers

Получается, что выравнивание данных на стеке, и выравнивание данных в полях структур выполняется разными способами?

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

Как правило структуры выравниваются по наибольшему значению, что в них присутствует, а не по машинному слову. В Вашем примере структура будет занимать 8 байт (каждое поле по 4 байта), что опять таки не годится, ведь на 64-битных машинах два переданных значения будут занимать в сумме 16 байт в стеке (что видно на схеме, которую я привёл в предыдущем посте).

[_Bers]

Сообщение от netrino

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

Как правило структуры выравниваются по наибольшему значению, что в них присутствует, а не по машинному слову. В Вашем примере структура будет занимать 8 байт (каждое поле по 4 байта), что опять таки не годится, ведь на 64-битных машинах два переданных значения будут занимать в сумме 16 байт в стеке (что видно на схеме, которую я привёл в предыдущем посте).

Вах вах! А я почему то думал, что структуры выравниваются так, что б были кратны машинному слову...

Ну вот взять например:

struct ddd
{
    LONG64 test; //8 байт
    char d;
};

cout<<sizeof(ddd)<<endl; //16 байт

7мь байт просто в никуда!

Я думал, что компиль выравнивает структуры так же, как и аргументы на стеке.

Но дело даже не в этом.

Дело вот в чем:

//взял адрес первого аргумента, и без проблем вытащил все аргументы, без необходимости копировать все аргументы
void Foo(int a1, int a2);

//Первый аргумент взялся без проблем. А вот второй уже не вывелся. Вместо корректного значения, в памяти оказался какой то мусор
void Foo(const int& a1, const int& a2);

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

Судя по поведению, во втором случае, компилятор разместил аргументы не один за другим на стеке, а черти как. Та область, которая якобы была предназначена для второго аргумента - там оказалось непонятное нечто.

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

Лучше пусть будет лишнее копирование всех аргументов, но это будет безопасно, контролируемо, и портируемо.

/зы Всякие макросы с которыми работают printf и компания - не помогли. Я так и не понял причину мусора на месте второго аргумента.

[netrino]

Сообщение от _Bers

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

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

Сообщение от _Bers

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

Лучше пусть будет лишнее копирование всех аргументов, но это будет безопасно, контролируемо, и портируемо.

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