Использование «стража» вместо sizeof на массивах

А если массив выделяется через malloc?

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

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

а потом раз за разом крутить цикл по всем элементам

Да, наверное поэтому. Как-то я об этом не подумал

Удобно же: в цикле на !NULL проверяешь — и все! А размер пришлось бы в структуре хранить, т.к. как ты динамический массив sizeof'ом?

А может и поэтому. Видимо есть такая традиция в си. Просто вижу впервые)

клёво. передавать 4 числа (в примере, N в теории) вместо одного.

Короче, эдакий аналог null-terminated строк, который приходится использовать за неимением оператора length

на самом деле, вспомните С-строки. классический пример, когда такое действительно удобно: получаем экономию памяти, причём, возможно, весьма существенную, т.к. строк может много и они могут сравнимой с int длины, строки часто приходится перебирать от начала до конца, поэтому накладные расходы на получение размера — небольшие.

который приходится использовать за неимением оператора length

такой оператор в С легко реализуется, просто этот самый оператор потребует хранить (как и в любом другом ЯП) размер массива, а это накладно. однако, неясно, зачем так делать вообще на всех массивах структур: в приведённом примере, проще, как раз Length передавать.

Все равно ведь меньше телодвижений. В данном случае обрабатываем так:

int fn(struct ColorTable *ptr){
    if(!ptr) return E_EMPTY;
    for(; ptr->name; ptr++){
        ... // делаем чавой-то
    }
    return 0;
}

struct ColorTable {
    size_t size;   
    char *name;
    unsigned char red, green, blue;
}

int fn(struct ColorTable *ptr){
    if(!ptr) return E_EMPTY;
    size_t i, L = ptr->size;
    for(i = 0; i < L; i++, ptr++){
        ... // делаем чавой-то
    }
    return 0;
}

Ну и каждый раз при модификации придется не забывать этот size обновлять.

за неимением оператора length

Напиши свой.

Да. Со строками ведь та же история: скажем, выделил ты буфер в килобайт под строчку. И, допустим, потихоньку читаешь в нее кусочками по 1-100 байт. В итоге каждый раз помимо memcpy тебе еще надо будет обновить length. Но в некоторых случаях действительно имеет смысл строки реализовать так:

typedef struct{
    char *text;
    size_t length;
} string;
...
    string some_str;
    some_str.text = strdup(argv[1]);
    some_str.length = strlen(some_str.text);
...

printf("argv[1] = %s, its length is %zd\n", (char*)&some_str, some_str.length)

printf("argv[1] = %s, its length is %zd\n", some_str.text, some_str.length)

однако, неясно, зачем так делать вообще на всех массивах структур:

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

Просто вижу впервые)

На самом деле очень распространенный подход, конформный со строками заканчивающимися на '\0'. Да и проще гораздо. Сам сравни:

size_t nelem = sizeof(colortable) / sizeof(colortable[0]);
int i;

for (i = 0; i < nelem; i++) {
        puts(colortable[i].name);
}

struct ColorTable *cp;

for (cp = colortable; cp->name != NULL; cp++) {
        puts(cp->name);
}

При этом, как уже сказали выше, первый подход работает только со «статическими» массивами, а второй как со «статикой», так и с «динамикой» (malloc).

#define SIZEOF(X) sizeof(X)/sizeof(X[0])

int i; 
for (i = 0; i < SIZEOF(colortable); i++) {
        puts(colortable[i].name);
}

вообще-то. причём, SIZEOF определён один раз и навсегда.

Ну и каждый раз при модификации придется не забывать этот size обновлять.

size всё равно придётся обновлять: записал на место нулевой структуры что-то - будь добр дописать в конец массива нулевую структуру опять. причём опять получаем бОльшие накладные расходы.

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

Проблема в том, что при передаче массива в функцию, массив оборачивается указателем, с которого sizeof() не сделать. И что делать?

1. не использовать функции, юзать массив от и до. Говнокод.

2. передавать размер. Хороший подход, но чреват ошибками(можно ошибиться в размере)

3. использовать «стража». Это работает, но к сожалению только если есть некое «особое» значение, например 0, или NaN (для чисел).

ЗЫЖ как бонус, многие алгоритмы ускоряются.

for(j=0; j<sz; j++)
{
  // обработка a[j]
}

// vs

for(p = a; *p; p++)
{
  // обработка *p
}

ускорение тут во первых из-за отсутствия лишней переменной j(работа с *p подразумевается), во вторых из-за упрощения адресации, ведь a[j] == *(a +j*sizeof(*a)).

#define SIZEOF(X) sizeof(X)/sizeof(X[0])

тебе так сложно немного лишних букв написать? Жалко 5и секунд? Эти пять секунд сэкономят тебя 5 недель на сопровождении.

кстати, почему не так?

int fn(struct ColorTable *ptr, int size){
    size_t i;
    for(i = 0; i < size; i++){
        ... // делаем чавой-то
    }
    return 0;
}

отнюдь. SIZEOF один раз пишется, а используется всю жизнь. в итоге повышается и читабельность кода, и скорость печати.

Во первых, ты забыл скобки. ;)

#define nelem(x) (sizeof(x)/sizeof((x)[0]))

А во вторых, ты вычисляешь размер при каждой итерации for.

И ещё раз: этот подход не работает с динамически выделенными массивами.

причём читается не только мной: большинство сишников используют независимо друг от друга этот макрос, причём, с тем же или крайне похожим названием (SIZE_OF видел как вариант)

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

Тебе решать…

А во вторых, ты вычисляешь размер при каждой итерации for.

нет. Любой вменяемый компилятор вычислит это константное выражение во время компиляции.

да-да, скобки (хотя, как раз для SIZEOF не критично, ну да лан). я же говорю: один раз написал, а потом уже и забыл.

А во вторых, ты вычисляешь размер при каждой итерации for.

нет, потому, что sizeof вычисляется на этапе компиляции, это константа.

Использование «стража» вместо sizeof на массивах (комментарий)

причём читается не только мной

удивил. Я тоже говнокодер. И имя нам — легион. Вот только некоторые стараются не быть говнокодерами, а стать нормальными кодерами, а другим и так неплохо.

это не говногод. SIZEOF(something) читается и отлаживается лучше sizeof(something)/sizeof(something[0]).

повышается и читабельность кода

Получается SIZEOF, делающий совсем не то, что ожидают от sizeof

да вы что! наверное, поэтому, он и записывается по-другому, не?

человек без сишки головного мозга старается избегать дефайнов, это можно понять

В этом случае придется отдельно размер вычислять. Нафиг-нафиг!

Хоть бы он SiZeOf писался, всё равно он состоит ровно из тех же букв в том же порядке. Кроме тебя нет дураков, которые будут ожидать от комманды cp копирования файла, а от CP - форматирования диска

SIZEOF(something) читается и отлаживается лучше sizeof(something)/sizeof(something[0]).

при программировании нужно и так Over9000 вещей помнить, нахрена свою память загаживать лишним? SIZEOF, SIZE_OF… Откуда я знаю, что это говно делает в твоём коде, и не забыл-ли ты опять скобки?

и не забыл-ли ты опять скобки?

Ха!

он человек с сишкой ГМ, а я как раз — нет. вот что не сходится в вашей теории.

а так, что — не придётся? да ладно...

а ты не виляй. написал дефайн — расписался в сишке гм)

он человек с сишкой ГМ

обоснуй

а я как раз — нет

спроси любого психа — он скажет «а я как раз — нет».

и не забыл-ли ты опять скобки?

хоть бы и забыл, то что? пусть будет даже

#define nelem(x) sizeof(x)/sizeof((x)[0])

чем грозит?

Откуда я знаю, что это говно делает в твоём коде

RM click -> find declaration of ... -> profit!

ну если так судить, то конечно. у разрабов плюсов видать Си ГМ поголовно...

обоснуй

beastie сишник, но не плюсовик, насколько я мог судить по его сообщениям ранее.

спроси любого психа — он скажет «а я как раз — нет».

Qt-шник с Си ГМ == /0

...а ещё у разрабов Qt тоже видать Си ГМ...

чем грозит?

типичная логика говнокодера.

RM click -> find declaration of ... -> profit!

удобочитаемость по next_time'овски.

beastie сишник, но не плюсовик

а если сишник и плюсовик?

Qt-шник с Си ГМ == /0

кутья межушного ганглия?

а ещё у разрабов Qt тоже видать Си ГМ...

и у дворника Мамеда тоже…

Дал.Дейкстра.Хоор. Структурное программирование.

часть2 О структурной организации данных.

2.8 Последовательность.

ps. последовательность ширше массива понятия.

И ты, без сишки ГМ, не стараешься избегать дефайнов?

Нет. Тебе тупо не нужно знать размер.