[n00b]Как смаллочить тип int (*)[4]?

apl13

Имеется библиотека, в которой такое вот объявление:


struct v_buffer {

 int (*color)[4];

};



struct v_buffer *vb;

Попытки написать:


vb->color = malloc( 4 * 300 * sizeof( int ;

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

yolki

у тебя такая ситуация:


 for(i=0;i<4;i++)

 {

   vb->color[i]=malloc(300*sizeof(int;

 }

pitrik2

for(int i=0;i<4;i++) {

  vb->color[i] = malloc(300 * sizeof( int ; 

}

apl13

Гм.


int (*a)[4];

for(i=0;i<4;i++)

{

/*14*/ a[i]=malloc(10*sizeof(int;

}


arr.c: In function `main':
arr.c: 14: incompatible types in assignment
Я всегда считал, что int (*)[4] - это указатель на массив, а не наоборот.

apl13

Иными словами, ни в одном компиляторе (мне их доступно два, с разными фронтэндами) такое не работает.

fufa58

arr.c: In function `main':arr.c: 14: incompatible types in assignment
мб тогда
 for(int i=0;i<4;i++) {

  vb->color[i] = (int*)malloc(300 * sizeof( int ; 

}

apl13

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

fufa58

del, туплю

pitrik2

Я всегда считал, что int (*)[4] - это указатель на массив, а не наоборот.
что значит наоборот?
int - переменная
int* - массив переменной длины
int[4] - массив длины 4
int[4][4] - двумерный массив 4 на 4, в нем 16 элементов, обращаться к ним через строчки и столбцы
(int*)[4] - двумерный массив у которого 4 строки и переменное число столбцов
(int[4])* - двумерный массив у которого 4 столбца и переменное число строк
int** - двумерный массив с переменным числом строк и переменным числом столбцов
все что переменное можно выделить malloc
все что не переменное выделить нельзя!
(int*)[4] = malloc - нельзя
(int[4])* = malloc - можно
не забываем никогда приводить типы, тоесть перед malloc в скобках ставить желаемый тип

apl13

Ну это как раз маллок.
Другой компилятор пишет:
"arr.c", line 14: error: expression must be a modifiable lvalue
a[i]=(int *)malloc(10*sizeof(int;
^
Причем если смаллочить
a = (void *)malloc( 40 * sizeof( int ;
забив на ворнинг, то получится массив a[i][j], i = 0...9, j=0...3.

pitrik2

(int*)[4] - двумерный массив у которого 4 строки и переменное число столбцов
(int[4])* - двумерный массив у которого 4 столбца и переменное число строк
балин
по ходу дела напутал
(int*)[4] - двумерный массив у которого 4 столбца и переменное число строк
(int[4])* - двумерный массив у которого 4 строки и переменное число столбцов
тогда в первом случае для каждой строки выделяем столбцы
int *(color[4]);

color[0] = (int*)malloc(300*sizeof(int;

и во втором случае вы деляем все строки
int (*color)[4];

color = (int(*)[4])malloc(300*sizeof(int;

apl13

(int(*)[4])
Спасибо. Собственно, это мне и было нужно.
ЗЫ. Впрочем, как показала практика, (void *) тоже прокатывает...

pitrik2

Впрочем, как показала практика, (void *) тоже прокатывает...
и это безобразие
когда так пишешь то 1) не понимаешь, что ты хочешь выделить строки или столбцы
2) и компилятор тебе этого не подскажет

mira-bella

int* - массив переменной длины
не угадал
эта штука называется указатель на переменную типа int (или на первый элемент массива int-ов, в зависимости от использования)
"массив переменной длины" - это не синоним, а грубое заблуждение, которое приводит к очень смешным ошибкам типа чтения/записи информации через неинициализированный указатель и т.п., встречающимся обычно у новичков, не понимающих что такое указатели, динамическое выделение памяти и т.д..
А массивы переменной длинны тоже есть - они появились в последнем стандарте (ISO 9899:1999) и обозначаются иначе.
int** - двумерный массив с переменным числом строк и переменным числом столбцов
а эта штука называется указатель на указатель на int.
Здесь проблема "массива переменной длины", описанная выше, как бы возведена в квадрат: чтобы получилось функциональное подобие двумерного массива переменной размерности нужно сперва присвоить данной переменной (указателю на указатель) указатель на буфер указателей нужного размера, а потом заполнить этот буфер указателями на буферы для элементов - только после этого будет доступ к самим элементам, и все упомянутые буферы (динамически или статически выделенные) должны быть взаимно непересекающимися, иначе это уже не будет строго говоря "двумерным массивом переменной размерности".
(int*)[4] - двумерный массив у которого 4 строки и переменное число столбцов
а эта штука называется массивом из четырех указателей.
С ним аналогичная ситуация.
АВТОРУ ТРЕДА: не используй извращенческих типов данных, и тогда не будет никаких проблем с компиляцией и самое главное - с последующим выполнением. Многомерные массивы, указатели на массивы (не путать с указателями на первый элемент массива) и подобное - это порождение злого архимага Сотоны, в гораздо большей степени чем оператор goto (который многие почему-то не любят).

poi1981

извращенческие типы данных рулят.
в конце концов, что может быть читабельней, чем следующее простое объявление:
int f(int;

Werdna

Дэн, а может не стоит ТАК писать, а? Ну ведь сегфолтами потом завалишь себя. :/
Неужели просто * недостаточно и парочки функций для чтения/записи в соотв. хрень? Зато хоть будешь знать точно, где отваливается. :/

Ivan8209

> Многомерные массивы,
Как предлагаешь работать с хотя бы трёхразмерными тензорами?
Про всякие гиперкубы я пока промолчу, чтобы не ранить твоей психики.
> указатели на массивы <...> - это порождение злого архимага Сотоны
Предлагается автоматизировать пересборку и перезапуск программы,
если вдруг понадобилось удлиннить массив?
Или здравствуй, фортран, со статическим выделением памяти?
---
"Математик может говорить, что ему хочется,
но физик должен, хотя бы в какой-то мере, быть в здравом рассудке."

apl13

2&:
чуваки, я-то вообще ничего не использую, это до меня кто-то поиспользовал...

apl13

Довожу до твоего сведения, многомудрый, что allocatable arrays были еще в 77-м Фортране...

ava3443

да ну? разве не начиная с 90?

Ivan8209

Всем известно, что придумали для сосунков, настоящие программисты используют 66-й.
---
...Я работаю антинаучным аферистом...

mira-bella

извращенческие типы данных рулят.
не рулят, но указатели на функции не являются таковыми, если чо.
без указателей на функции иногда нельзя обойтись, а вот без многомерных массивов и иже с ними обойтись можно всегда и при этом код будет более читабельным.
в конце концов, что может быть читабельней, чем следующее простое объявление:
int f(int;

ох и читабельность же - трудно придумать что будет менее читабельно
(ИМХО если эта запись не вызывает синтаксическую ошибку - это тоже порождение Сотоны, а если вызывает, то и слава богу)
а более читабельно - все что угодно
например (если я вообще понял, что подразумевалось под "int f(int;"):


typedef int (*int_funcvoid);



int f(int_func Param);

или хотя бы:


int f( int (*Paramvoid) );

Ivan8209

> без многомерных массивов и иже с ними обойтись можно всегда
> и при этом код будет более читабельным.
И много ты написал кода хотя бы с двумерными такими массивами?
---
"Математик может говорить, что ему хочется,
но физик должен, хотя бы в какой-то мере, быть в здравом рассудке."

mira-bella

> Многомерные массивы,
Как предлагаешь работать с хотя бы трёхразмерными тензорами?
разумеется при помощи указателя на первый элемент, придумав заранее какое-то удобное для конкретной задачи расположение элементов тензора в памяти.
> без многомерных массивов и иже с ними обойтись можно всегда
> и при этом код будет более читабельным.
И много ты написал кода хотя бы с двумерными такими массивами?

да
> указатели на массивы <...> - это порождение злого архимага Сотоны
Предлагается автоматизировать пересборку и перезапуск программы,
если вдруг понадобилось удлиннить массив?
угога

обожаю чтение моих постов по диагонали с последующим выраванием фраз из контекста.
программистами в здравом уме для реализации динамического массива используется указатель на первый элемент массива (с которым я прямым текстом просил не путать и его типом является указатель_на_элемент, а не указатель_на_массив, хотя поскольку он указывает на начало расположения массива в памяти его можно назвать и указателем на массив. Эта двусмысленность понимания фразы "указатель на массив" является еще одним важным аргументом в пользу того, что C-шный тип указатель_на_массив - это порождение Сотоны.

Ivan8209

>> Как предлагаешь работать с хотя бы трёхразмерными тензорами?
> при помощи указателя на первый элемент разумеется,
> придумав заранее какое-то удобное для конкретной задачи расположение элементов тензора в памяти.
Вообще-то, языки высокого уровня, и си в том числе (как это ни странно
придумали именно для того, чтобы не запоминать такие вещи.
Хотя бы --- расположение данных в памяти.
>>> без многомерных массивов и иже с ними обойтись можно всегда
>>> и при этом код будет более читабельным.
>> И много ты написал кода хотя бы с двумерными такими массивами?
> да
Тогда я могу поздравить тебя.
Ты --- настоящий программист и закатывать солнце вручную --- твоё призвание.
Вот только не верю я, что постоянное выписывание в явном виде
смещения куда-то внутрь трёхмерного массива так уж читаемо.
Особенно на фоне сёвого одноуровневого пространства имён.
>>> указатели на массивы <...> - это порождение злого архимага Сотоны
>> Предлагается автоматизировать пересборку и перезапуск программы,
>> если вдруг понадобилось удлиннить массив?
> программистами в здравом уме для реализации динамического массива
> используется указатель на первый элемент массива
И размерности массива хранят отдельно, в том числе на бумажке,
в комментариях к программе и тому подобных местах.
> и его типом является указатель_на_элемент, а не указатель_на_массив,
Твои рассуждения на корню убивают некоторые способы оптимизации.
> Эта двусмысленность понимания фразы "указатель на массив"
> является еще одним важным аргументом в пользу того,
> что C-шный тип указатель_на_массив - это порождение Сотоны.
Двусмысленность только у тебя в голове.
Если судить по-твоему, то sizeof("string") должен быть равен размеру слова,
потому что "string" является ничем иным, как постоянным указателем,
либо размеру байта, потому что "string" является указателем на байт.
Это не так даже в си, не говоря уж про человеческое понимание,
как оно должно быть.
---
...Я работаю антинаучным аферистом...

poi1981

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

mira-bella

Вообще-то, языки высокого уровня, и си в том числе (как это ни странно
придумали именно для того, чтобы не запоминать такие вещи.
Хотя бы --- расположение данных в памяти.
Вот только не верю я, что постоянное выписывание в явном виде
смещения куда-то внутрь трёхмерного массива так уж читаемо.
Особенно на фоне сёвого одноуровневого пространства имён.
смешно даже такое комментировать
как говорится "плохому танцору и х** мешает"
Элементарная функциональность языка C такая как функции, макросы и т.п. позволяет сделать так, чтобы все было читабельно и запоминать ничего не пришлось.
А вот многомерные массивы являются например причиной глупых неоднозначностей, которые ухудшают читабельность, например если выражение "A[j][k]" имеет тип double, то какой тип имеет объект "A"? - Он может быть или указателем на указатель или многомерным массивом, что вопиюще различные и совершенно не взаимозаменяемые типы. Мелочь конечно, но досадно. А самое досадное, что эти многомерные массивы приходится реализовывать создателям компиляторов, вникая во всю их долбанутую логику плохо стыкующуюся с концепцией имени массива как константы-указателя на первый элемент, в то время как их почти никогда не используют в реальных приложениях, а вот "имя массива как константа-указатель на первый элемент" используется постоянно.
> программистами в здравом уме для реализации динамического массива
> используется указатель на первый элемент массива
И размерности массива хранят отдельно, в том числе на бумажке,
в комментариях к программе и тому подобных местах.
Где хотят, там и хранят.
Если размерность массива вообще нужна (т.е. если структура данных не имеет служебных ограничителей типа нулевого символа в C-строке то обычно хранят в специально предназначенной для этого переменной.
Твои рассуждения на корню убивают некоторые способы оптимизации.
оказывается я могущественный маг - одни лишь мои рассуждения убивают
О каких именно не любимых мной фичах и предоставляемых ими возможностях оптимизации идет речь?
> Эта двусмысленность понимания фразы "указатель на массив"
> является еще одним важным аргументом в пользу того,
> что C-шный тип указатель_на_массив - это порождение Сотоны.
Двусмысленность только у тебя в голове.
если учесть, что это я разъяснял суть этой двусмысленности, то не факт, что у меня
Разумеется эта двусмысленность в головах программистов, использующих C, где же ей еще быть. Именно это и проблема.
Если судить по-твоему, то sizeof("string") должен быть равен размеру слова,
потому что "string" является ничем иным, как постоянным указателем,
точнее размеру указателя (который вовсе не обязательно равен размеру слова)
может и так, но вообще и существующему положению вещей можно придумать логическое обоснование в рамках "жизни без многомерных массивов".
А вот если массив считать таким же типом как и все остальные, то почему например нельзя присвоить один массив другому при помощи оператора "="?
либо размеру байта, потому что "string" является указателем на байт.
а это с какого фига?
Это не так даже в си, не говоря уж про человеческое понимание,
как оно должно быть.
ну так в C тоже не так как в "человеческом понимании"

Ivan8209

>> Вот только не верю я, что постоянное выписывание в явном виде
>> смещения куда-то внутрь трёхмерного массива так уж читаемо.
>> Особенно на фоне сёвого одноуровневого пространства имён.
> Элементарная функциональность языка C такая как функции, макросы и т.п.
> позволяет сделать так, чтобы все было читабельно и запоминать ничего не пришлось.
Элементарная функциональность языка С позволяет выписывать многомерные массивы без заведения функций
и привлечения внешних средств, таких, как макроподстановки.
> А вот многомерные массивы являются например причиной глупых неоднозначностей,
> которые ухудшают читабельность, например если выражение "A[j][k]"
> имеет тип double, то какой тип имеет объект "A"? -
Очевидно, массив.
> Он может быть или указателем на указатель или многомерным массивом,
> что вопиюще различные и совершенно не взаимозаменяемые типы.
Ну да?
Если массив представлять указателем, то очень даже взаимозаменяемые.
> Мелочь конечно, но досадно.
Что досадно?
Что массив это самостоятельный тип данных, отличающийся, в общем случае, от указателя?
> А самое досадное, что эти многомерные массивы приходится реализовывать создателям компиляторов,
> вникая во всю их долбанутую логику плохо стыкующуюся с концепцией
> имени массива как константы-указателя на первый элемент,
Создателям _которых_ компиляторов?
Не вижу никаких трудностей. Массив не есть указатель, и это очевидно.
На разных архитектурах многомерный массив может представляться поразному,
это очевидно и не вызывает нареканий. То, как оно должно представляться,
очевидным образом зависит от машины, которая может не поддерживать
умножения, может поддерживать (быструю) выборку из одномерного
или сразу двумерного массива.
> в то время как их почти никогда не используют в реальных приложениях,
> а вот "имя массива как константа-указатель на первый элемент" используется постоянно.
Что ты называешь "реальными приложениями"?
Ты просто не умеешь писать на высокоуровневых языках.
Даже на таких низкоуровневых, как си.
Тебя огорчает тот факт, что массив не является указателем,
только потому, что с 70-х годов си стал употребляться не только
на машинах класса K-11 или M68K, но ещё и на куче сильно от них отличающихся,
взять хотя бы PIC, 8051, ARM и какой-нибудь DSP.
>>> программистами в здравом уме для реализации динамического массива
>>> используется указатель на первый элемент массива
>> И размерности массива хранят отдельно, в том числе на бумажке,
>> в комментариях к программе и тому подобных местах.
> Где хотят, там и хранят.
> Если размерность массива вообще нужна (т.е. если структура данных
> не имеет служебных ограничителей типа нулевого символа в C-строке
Идиотская привычка.
> то обычно хранят в специально предназначенной для этого переменной.
>> Твои рассуждения на корню убивают некоторые способы оптимизации.
> О каких именно не любимых мной фичах и предоставляемых ими возможностях оптимизации идет речь?
О той, что массив не есть указатель на элемент, хотя и может таковым являться.
В многомерном массиве A[][] главным является то, что A[][] является элементом.
При этом совершенно не важно то, чем являются A и A[].
Например, в целях оптимизации может быть удобно,
чтобы A был указателем на указатель, а не на элемент.
Собственно, думаю, даже на KA-11 было бы лучше именно так.
>>> Эта двусмысленность понимания фразы "указатель на массив"
>>> является еще одним важным аргументом в пользу того,
>>> что C-шный тип указатель_на_массив - это порождение Сотоны.
>> Двусмысленность только у тебя в голове.
> если учесть, что это я разъяснял суть этой двусмысленности, то не факт, что у меня
> Разумеется эта двусмысленность в головах программистов, использующих C, где же ей еще быть.
> Именно это и проблема.
Если использующем си программистом считать каждого, кто способен написать "a=b",
поставить точку с запятой и фигурные скобки, то да, это проблема.
>> Если судить по-твоему, то sizeof("string") должен быть равен размеру слова,
>> потому что "string" является ничем иным, как постоянным указателем,
> точнее размеру указателя (который вовсе не обязательно равен размеру слова)
> может и так, но вообще и существующему положению вещей
> можно придумать логическое обоснование в рамках "жизни без многомерных массивов".
Придумывай.
> А вот если массив считать таким же типом как и все остальные,
> то почему например нельзя присвоить один массив другому при помощи оператора "="?
Так устроен мир.
А на самом деле, есть ещё и соображение "чтобы не писали медленный код."
>> либо размеру байта, потому что "string" является указателем на байт.
> а это с какого фига?
Потому что любая переменная --- это постоянный указатель,
который имеет свойство разыменовываться при присваивании,
а когда ты пишешь "float a", то ожидаешь, что "sizeof(a)" вернёт размер
числа, а не указателя.
>> Это не так даже в си, не говоря уж про человеческое понимание,
>> как оно должно быть.
> ну так в C тоже не так как в "человеческом понимании"
Обоснуй.
---
...Я работаю антинаучным аферистом...

mira-bella

Элементарная функциональность языка С позволяет выписывать многомерные массивы без заведения функций
только фиксированной размерности, только с определенным расположением элементов в памяти
> Он может быть или указателем на указатель или многомерным массивом,
> что вопиюще различные и совершенно не взаимозаменяемые типы.
Ну да?
да, прикинь.
ботай матчасть
Если массив представлять указателем, то очень даже взаимозаменяемые.
"Если бы у бабушки был х**, она была бы дедушкой."
Согласно стандарту синтаксически не взаимозаменяемые, например если в функции int f(double** p) в качестве аргумента передать двумерный массив из double-ов, то компилятор скажет про "cannot convert types bla-bla-bla", и аналогично, если в int f(double a[4][4]) передать double** p.
На разных архитектурах многомерный массив может представляться поразному,
это очевидно и не вызывает нареканий.
Это не только не очевидно, но и абсолютно неверно.
Стандарт однозначно определяет как многомерный массив представляется в памяти.
О той, что массив не есть указатель на элемент, хотя и может таковым являться.
конечно
массив - это последовательность элементов, расположенных в памяти один за другим.
(n+1)-мерный массив - это массив n-мерных массивов, т.е. последовательность n-мерных массивов, расположенных в памяти один за другим.
Что ты называешь "реальными приложениями"?
Используемые на практике приложения (желательно кем-либо кроме автора). В отличие от учебных приложений, proof_of_concept-приложений, и т.п.
> А вот если массив считать таким же типом как и все остальные,
> то почему например нельзя присвоить один массив другому при помощи оператора "="?
Так устроен мир.
А на самом деле, есть ещё и соображение "чтобы не писали медленный код."
Вопрос был риторический и ответ известен и очевиден, но это конечно не упомянутое тобой соображение.
Потому что любая переменная --- это постоянный указатель,
который имеет свойство разыменовываться при присваивании,
что за чушь
Как насчет переменных хранящихся в регистрах?
Переменная - это именованный типизированный блок информации определенного размера (определенного типом переменной конечно и sizeof разумеется возвращает размер этого блока информации.
> ну так в C тоже не так как в "человеческом понимании"
Обоснуй.
sizeof("string") не равен количеству букавок в "string" очевидно.

Maurog

sizeof("string") не равен количеству букавок в "string" очевидно
sizeof("string") = 7
на единичку отличается всего
не так уж и страшно

Ivan8209

>> Элементарная функциональность языка С позволяет
>> выписывать многомерные массивы без заведения функций
> только фиксированной размерности,
> только с определенным расположением элементов в памяти
Это низкоуровневые ограничения.
Последнее, причём, сомнительно и требует проверки.
Это надо лезть в /tmp, файл создавать...
> Согласно стандарту синтаксически не взаимозаменяемые,
> например если в функции int f(double** p) в качестве аргумента
> передать двумерный массив из double-ов, то компилятор скажет
> про "cannot convert types bla-bla-bla", и аналогично,
> если в int f(double a[4][4]) передать double** p.
И правильно сделает.
Потому что преобразование привлекает сведения об архитектуре.
>> На разных архитектурах многомерный массив может представляться поразному,
>> это очевидно и не вызывает нареканий.
> Это не только не очевидно, но и абсолютно неверно.
> Стандарт однозначно определяет как многомерный массив представляется в памяти.
Это не только верно, но ещё и правильно.
Если стандарт ломает устоявшуюся практику, тем хуже для стандарта.
>> О той, что массив не есть указатель на элемент, хотя и может таковым являться.
> конечно
> массив - это последовательность элементов, расположенных в памяти один за другим.
Да ну?
Ты про выравнивание никогда ничего не слышал?
> (n+1)-мерный массив - это массив n-мерных массивов,
> т.е. последовательность n-мерных массивов,
> расположенных в памяти один за другим.
Это не так.
>> Что ты называешь "реальными приложениями"?
> Используемые на практике приложения (желательно кем-либо кроме автора).
> В отличие от учебных приложений, proof_of_concept-приложений, и т.п.
Ну так вот.
Компилятор си для Z80 размещает массивы совсем не так,
как ты думаешь, а более эффективно, потому что у Z80 нет
аппаратного умножения.
То же самое применимо для мотороллеров.
Даже для некоторых из семейства 68000.
У последних есть быстрая выборка из двумерного массива,
поэтому из массивы большей размерности имеет смысл выделять
два первых или последних измерения для отдельной выборки.
>> Потому что любая переменная --- это постоянный указатель,
>> который имеет свойство разыменовываться при присваивании,
> что за чушь
> Как насчет переменных хранящихся в регистрах?
Это ересь.
Это такое исключение, как и особо летучие переменные,
которые нельзя держать в регистрах.
Соответственно, они могут иметь особенности обработки.
> Переменная - это именованный типизированный блок информации
> определенного размера (определенного типом переменной конечно
> и sizeof разумеется возвращает размер этого блока информации.
Ты никогда не сталкивался с тем, что один и тот же компилятор,
в зависимости от того, что ему сказать, может выравнивать
или не выравнивать размеры до какой-нибудь границы?
Из-за этого, в частности, приходится извращаться с записями,
которые неожиданно вырастают с 78 октетов до 80.
>>> ну так в C тоже не так как в "человеческом понимании"
>> Обоснуй.
> sizeof("string") не равен количеству букавок в "string" очевидно.
Очевидно, что это является человеческим пониманием размера,
который выражается в единицах длины, а не в штуках.
Это ясно даже самым тупым программистам, которые знают,
что важно, у кого длиннее, а не у кого есть.
---
...Я работаю антинаучным аферистом...

mira-bella

> Согласно стандарту синтаксически не взаимозаменяемые,
> например если в функции int f(double** p) в качестве аргумента
> передать двумерный массив из double-ов, то компилятор скажет
> про "cannot convert types bla-bla-bla", и аналогично,
> если в int f(double a[4][4]) передать double** p.
И правильно сделает.
что и требовалось доказать
Да ну?
Ты про выравнивание никогда ничего не слышал?
прикинь слышал
и оно не отменяет того, что я сказал
Если стандарт ломает устоявшуюся практику, тем хуже для стандарта.
скорее тем хуже для "устоявшейся практики"
стандарт обычно обобщает устоявшуюся практику,
и если некие особенности каких-то реализаций противоречат стандарту, подозреваю, что они не являются устоявшейся практикой.
Компилятор си для Z80 размещает массивы совсем не так,
как ты думаешь, а более эффективно, потому что у Z80 нет
аппаратного умножения.
То же самое применимо для мотороллеров.
Даже для некоторых из семейства 68000.

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

а прикинь sizeof(char)==1 согласно стандарту, так что размер выражающийся в единицах длины равен количеству в штуках.

mira-bella

> Переменная - это именованный типизированный блок информации
> определенного размера (определенного типом переменной конечно
> и sizeof разумеется возвращает размер этого блока информации.
Ты никогда не сталкивался с тем, что один и тот же компилятор,
в зависимости от того, что ему сказать, может выравнивать
или не выравнивать размеры до какой-нибудь границы?
в зависимости от опций?
Конечно. И что?
паддинг выравнивания - это тоже часть означенного типизированного блока информации.
А если компилятор в зависимости от опций по разному представляет структуру типов, то эти опции как бы переключают между разными реализациями языка C (что вообще-то идиотская практика).

Ivan8209

>> Если стандарт ломает устоявшуюся практику, тем хуже для стандарта.
> скорее тем хуже для "устоявшейся практики"
Из-за таких стандартов есть устоявшаяся практика плевать на стандарты и делать так, как надо.
> стандарт обычно обобщает устоявшуюся практику,
> и если некие особенности каких-то реализаций противоречат стандарту,
> подозреваю, что они не являются устоявшейся практикой.
"Обычно" не означает всегда.
Иногда стандарт нагло плюёт на целые области практической деятельности.
>> Компилятор си для Z80 размещает массивы совсем не так,
>> как ты думаешь, а более эффективно, потому что у Z80 нет
>> аппаратного умножения.
> о каких именно компиляторах речь (с номерами версий)?
Чтоб я помнил!
Тебе это так надо?
Хорошо, я запомню.
Когда найду или вспомню, напишу.
Я сам был удивлён, когда увидел такое, почему и запомнил.
> а прикинь sizeof(char)==1 согласно стандарту,
> так что размер выражающийся в единицах длины равен количеству в штуках.
Ну, у меня другой стандарт, и в нём "4 chars" может быть больше, чем 4.
У меня даже буквы длиннее.
---
...Я работаю антинаучным аферистом...

Ivan8209

> если компилятор в зависимости от опций по разному представляет структуру типов,
> то эти опции как бы переключают между разными реализациями языка C
> (что вообще-то идиотская практика).
То есть, ты считаешь нормальным писать программы на си в стиле "int *main = { 012, 023, 034 };"
или с использованием других архитектурнозависимых подробностей?
---
...Я работаю антинаучным аферистом...

mira-bella

Ну, у меня другой стандарт,
собственного сочинения?

Ivan8209

ANSI X3.215--1994.
---
...Я работаю антинаучным аферистом...

mira-bella

То есть, ты считаешь нормальным писать программы на си в стиле "int *main = { 012, 023, 034 };"

ужос нах
что за стиль такой?
Я считаю нормальным писать программы на C совместимые с его стандартом, читабельные и портируемые (в известных рамках конечно). Естественно по возможности не делающие ставку на особенности реализации.

mira-bella

ANSI X3.215--1994.
сбрось на мыло, плиз
см. ПМ

maggi14

То есть, ты считаешь нормальным писать программы на си в стиле "int *main = { 012, 023, 034 };"
Какая прелесть Нет, я обязательно напишу что-нибудь такое на досуге например, можно попытаться сделать программу с таким main, выводящую саму себя на печать

Ivan8209

>> То есть, ты считаешь нормальным писать программы на си в стиле "int *main = { 012, 023, 034 };"
> что за стиль такой?
http://www.ioccc.org/years.html#1984_mullender
> Я считаю нормальным писать программы на C совместимые с его стандартом,
> читабельные и портируемые (в известных рамках конечно).
> Естественно по возможности не делающие ставку на особенности реализации.
Представление объекта в памяти --- это всегда особенность реализации,
если язык предназначен для работы на нескольких разных архитектурах.
---
...Я работаю антинаучным аферистом...

apl13

А может, и в 90-м. Что такое тринадцать лет в сравнении с возрастом цивилизации? А в геологическом масштабе? Пойду покурю.

mira-bella

> Я считаю нормальным писать программы на C совместимые с его стандартом,
> читабельные и портируемые (в известных рамках конечно).
> Естественно по возможности не делающие ставку на особенности реализации.
Представление объекта в памяти --- это всегда особенность реализации,
если язык предназначен для работы на нескольких разных архитектурах.
к сожалению да, и это делает невозможным разработку портируемых бинарных структур, которые часто бывают необходимы, поэтому в некоторых случаях на особенности реализации (некоторые такие особенности присутствуют практически во всех реализациях) или языковые расширения приходится делать ставку.
невозможность определить портируемую бинарную стуктуру я считаю одним из главных недостатков C, т.к. эта функциональность бывает необходима для многих приложений (поддержка сетевых протоколов, файловых систем, мультимедийных форматов, архивов и т.п.).

Landstreicher

> ANSI X3.215--1994.
Где такое старье выкопал? И самое главное, зачем?

Ivan8209

>> ANSI X3.215--1994.
> Где такое старье выкопал?
А он самопродлевается, если не был заменён в течение четырёх, что ли, или пяти лет.
Если он жив уже третий срок, значит, не было нужды его менять.
Так что не надо говорить про старьё, а то я ANSI X3.159--1989 вырою.
> И самое главное, зачем?
А почему бы и нет?
У меня есть свежие RfD, так что от жизни я не отстаю.
Ты-то вообще грабли ловишь на хаскеле. Зачем?
---
...Я работаю антинаучным аферистом...

Ivan8209

>> Представление объекта в памяти --- это всегда особенность реализации,
> это делает невозможным разработку портируемых бинарных структур
> невозможность определить портируемую бинарную структуру
> я считаю одним из главных недостатков C, т.к. эта функциональность
> бывает необходима для многих приложений (поддержка сетевых протоколов,
> файловых систем, мультимедийных форматов, архивов и т.п.).
Поэтому раньше заводили такой тип данных, как строка бит (PL/I и семейство
и ещё делали аппаратную поддержку поразрядного доступа.
---
...Я работаю антинаучным аферистом...

Landstreicher

> А он самопродлевается, если не был заменён в течение четырёх, что ли, или пяти лет.
> Если он жив уже третий срок, значит, не было нужды его менять.
А как же C99?

Ivan8209

> А как же C99?
И много ты знаешь соответствующих компиляторов?
А программ?
---
...Я работаю антинаучным аферистом...
Оставить комментарий
Имя или ник:
Комментарий: