LINUX.ORG.RU

История изменений

Исправление drBatty, (текущая версия) :

Ну дык! ... .. по поводу амнезии, не знаю. Я для «верочки-контрольки» не гнушаюсь интересоваться через sizeof(something).

а вот зря. Можно и на грабли наступить: 

#include <stdio.h>

void f(int a[])
{
·   printf("size(a[11]) %lu\n",
·   ·   ·   sizeof(a)/sizeof(a[0]));
}

int main()
{
·   int a[11] = {0};
·   printf("size(a[11]) %lu\n",
·   ·   ·   sizeof(a)/sizeof(a[0]));
·   f(a);
·   return 0;
}
выхлоп 
size(a[11]) 11
size(a[11]) 2
Т.е. в первом случае размер правильный (11 эл-тов), а во втором - фигня. Двойка. А так получилось потому, что размер указателя у меня вдвое больше размера int'а.

И это притом, что я ЯВНО указал, что аргумент - это массив, а не указатель!

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

а что, malloc(2) сломался?

Про K&R. Ну да... Всё бы на ошибки проектировщика списать (поговорку про дурака со стеклянным хером напомнить?).

не надо. В данном случае это ИМХО вправду fail K&R. Массивы сделали, а вот их передачу оставили «на потом». Даже форму передачи запилили, только вместо реализации поставили затычку - оно реализовано тем же кодом, что и передача указателя. А потом менять что-то было уже поздно - нашлись идиоты, для которых прозрачный хер жизненно необходим...

Если нубу не под силу С, то лучше бы ему заняться чем-то типа похапе.

NoWay. Если в сишечке совсем немного таких фэйлов, то пхп наполнен ими чуть более, чем полностью. И их периодически исправляют(кроме шуток). И тонны быдлокода вылетают в помойку.

С позволяет работать «от положения» (в том числе и убивать систему), а не делать всё, что угодно одним самым лучшим способом, т.к. для такого подхода есть питон. Но остаётся вопрос — а для какого случая _этот_ способ самый лучший? Для моего?

не. Для компилятора. Компилятору нужны такие конструкции, которые он сможет адекватно переложить на любую архитектуру. Ну это в сишечке такой подход, в перловках да в пайтонах другой подход:

1. курим шишки и мечтаем: чего я хочу? Хочу массивы? Легко! Хочу хеши? ОК! Как список в скаляр преобразуется? Щаз... Пыхну... А! Твак и преобразуется, один косяк пыхнул, второй косяк пыхнул... Какой я косяк только-что пыхнул? БЛЖАД! Последний! Очевидно же? Так сколько я косяков пыхнул? Дура чёли? 28! Но это уже если рассматривать косяки как массив!

2. Курим ещё шышек, и придумываем закорючки

3. профит.

Т.е., питон хорош, но когда нужна скорость, всё-таки используйте С. А зачем? Я и так на С пишу. Мне питон не нужен.

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

alloca нужен просто потому, что в ряде случаев он несколько быстрее

быстрее чего? Локального массива? Если мне нужен массив на 10 int'ов, то я так и напишу int[10], всё равно его не отдать никому. А если я не знаю, и может мне нужно int[100500], то мне alloca() не помощник.

Про advantages — http://www.gnu.org/software/libc/manual/html_mono/libc.html#Advantages-of-Alloca, про disadvantages там же, чуть ниже.

ну это для embedded разве что интересно, если тебе нужен массив в 20..30 эл-тов, и ты хочешь каждый байт сэкономить (я просто напишу int[32]).

Исходная версия drBatty, :

Ну дык! ... .. по поводу амнезии, не знаю. Я для «верочки-контрольки» не гнушаюсь интересоваться через sizeof(something).

а вот зря. Можно и на грабли наступить: 

#include <stdio.h>

void f(int a[])
{
·   printf("size(a[11]) %lu\n",
·   ·   ·   sizeof(a)/sizeof(a[1]));
}

int main()
{
·   int a[11] = {0};
·   printf("size(a[11]) %lu\n",
·   ·   ·   sizeof(a)/sizeof(a[1]));
·   f(a);
·   return 0;
}
выхлоп 
size(a[11]) 11
size(a[11]) 2
Т.е. в первом случае размер правильный (11 эл-тов), а во втором - фигня. Двойка. А так получилось потому, что размер указателя у меня вдвое больше размера int'а.

И это притом, что я ЯВНО указал, что аргумент - это массив, а не указатель!

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

а что, malloc(2) сломался?

Про K&R. Ну да... Всё бы на ошибки проектировщика списать (поговорку про дурака со стеклянным хером напомнить?).

не надо. В данном случае это ИМХО вправду fail K&R. Массивы сделали, а вот их передачу оставили «на потом». Даже форму передачи запилили, только вместо реализации поставили затычку - оно реализовано тем же кодом, что и передача указателя. А потом менять что-то было уже поздно - нашлись идиоты, для которых прозрачный хер жизненно необходим...

Если нубу не под силу С, то лучше бы ему заняться чем-то типа похапе.

NoWay. Если в сишечке совсем немного таких фэйлов, то пхп наполнен ими чуть более, чем полностью. И их периодически исправляют(кроме шуток). И тонны быдлокода вылетают в помойку.

С позволяет работать «от положения» (в том числе и убивать систему), а не делать всё, что угодно одним самым лучшим способом, т.к. для такого подхода есть питон. Но остаётся вопрос — а для какого случая _этот_ способ самый лучший? Для моего?

не. Для компилятора. Компилятору нужны такие конструкции, которые он сможет адекватно переложить на любую архитектуру. Ну это в сишечке такой подход, в перловках да в пайтонах другой подход:

1. курим шишки и мечтаем: чего я хочу? Хочу массивы? Легко! Хочу хеши? ОК! Как список в скаляр преобразуется? Щаз... Пыхну... А! Твак и преобразуется, один косяк пыхнул, второй косяк пыхнул... Какой я косяк только-что пыхнул? БЛЖАД! Последний! Очевидно же? Так сколько я косяков пыхнул? Дура чёли? 28! Но это уже если рассматривать косяки как массив!

2. Курим ещё шышек, и придумываем закорючки

3. профит.

Т.е., питон хорош, но когда нужна скорость, всё-таки используйте С. А зачем? Я и так на С пишу. Мне питон не нужен.

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

alloca нужен просто потому, что в ряде случаев он несколько быстрее

быстрее чего? Локального массива? Если мне нужен массив на 10 int'ов, то я так и напишу int[10], всё равно его не отдать никому. А если я не знаю, и может мне нужно int[100500], то мне alloca() не помощник.

Про advantages — http://www.gnu.org/software/libc/manual/html_mono/libc.html#Advantages-of-Alloca, про disadvantages там же, чуть ниже.

ну это для embedded разве что интересно, если тебе нужен массив в 20..30 эл-тов, и ты хочешь каждый байт сэкономить (я просто напишу int[32]).