си C99

что за компилятор?

gсс 4.7.2-5 (debian amd64)

Что Вы думаете по поводу использования этого стандарта?

спустя 15 лет, уже можно использовать

У меня обычно -std=gnu99

скоро значением по умолчанию будет gnu11: GCC 5 Release Series Changes, New Features, and Fixes:

The default mode for C is now -std=gnu11 instead of -std=gnu89.

Юникод же двухбайтовый (а то и больше), как его в массив char (1 байт на всех популярных архитектурах) запихнуть то? Разве что UTF-8, но с этим справляется любой текстовый редактор - в файл то сохранится уже готовая строка, а компилятору всё равно в какой кодировке текст в строковой константе - хоть в UTF-8, хоть в КОИ-8, хоть в Windows-1251.

да, странно это, c99 все как-то перепрыгнули

если не требуется поддержка MSVC — однозначно стоит.

(насчет vs2015 не уверен, может реализовали..)

с99 великолепная штука, и да, я пользуюсь.

На С99 удобнее писать что ли. А по сути тот же С89, только вид с боку.

Это из за значения юникода (типа \u2663) в массиве char

ну ты тупой, не? Char в x86 размером 1 байт, а твоё говно «♣» — 3 байта. Ну и как ты 3 байта в один затолкаешь?

Два решения:

1. wchar_t и постфикс L (не сработает в маздае, там wchar_t 16 бит, и этот символ не влезет)

2.

$ echo -e "\xE2\x99\xA3"
♣ # uses UTF-8

уже используют c11 в системных компонентах

как

u8"♣"

атата, топик про с99, май бэд

Использовать — стоит. Если у тебя уже есть готовый проект, и это — единственный варнинг, а, по твоим словам, ты можешь обойтись — обойдись.

Кстати, интересно. systemd компилится с -std=gnu99, однако там ничего С99-специфичного, вроде, нет.

Кстати, интересно. systemd компилится с -std=gnu99, однако там ничего С99-специфичного, вроде, нет.

Ну я открыл пару файлов первых попавшихся:

/* src/core/job.c @ 1226 */
static const char* const job_result_table[_JOB_RESULT_MAX] = {
    [JOB_DONE] = "done",
    [JOB_CANCELED] = "canceled",
    [JOB_TIMEOUT] = "timeout",
    [JOB_FAILED] = "failed",
    [JOB_DEPENDENCY] = "dependency",
    [JOB_SKIPPED] = "skipped",
    [JOB_INVALID] = "invalid",
    [JOB_ASSERT] = "assert",
    [JOB_UNSUPPORTED] = "unsupported",
};

/* src/core/manager.c @ 1518 */
struct iovec iovec = {
    .iov_base = buf,
    .iov_len = sizeof(buf)-1,
};

[ecko@localhost develop]$ cat ctest.c
#include <stdio.h>

struct fst {
  int a;
  int b;
};

int main(void)
{
  struct fst f = {
    .a = 0,
    .b = 2,
  };
  printf("a=%d\tb=%d\n", f.a, f.b);
  return 0;
}
[ecko@localhost develop]$ gcc -o ctest ctest.c -Wall -std=c89
[ecko@localhost develop]$      

Что я сделал не так?

Всё так, просто здесь это расширение gcc:

$ gcc test.c -Wall -pedantic -std=c89
test.c: In function ‘main’:
test.c:11:9: warning: ISO C90 forbids specifying subobject to initialize [-Wpedantic]
         .a = 0,
         ^
test.c:12:9: warning: ISO C90 forbids specifying subobject to initialize [-Wpedantic]
         .b = 2,
         ^

Ну-у-у-у, -pedantic — это другой разговор. pedantic и на такой код ругается.

[ecko@localhost develop]$ cat ctest2.c
#include <stdio.h>

int main(void)
{
  int a = 0;
  printf("%d\n", a);
  int b = 1;
  printf("%d\n", b);
  return 0;
}
[ecko@localhost develop]$ gcc -o ctest2 ctest2.c -std=c89 -pedantic
ctest2.c: В функции «main»:
ctest2.c:7:3: предупреждение: ISO C90 forbids mixed declarations and code [-Wpedantic]
   int b = 1;
   ^
[ecko@localhost develop]$

Но в целом — ясно. Спасибо!

У меня обычно -std=gnu99

У тебя и звезды все зокрашыны, и на аве Эрег руки-ножницы :)

С -std=gnu99 ругаться не будет. И на объявление итераторов внутри for — тоже.

У меня-то компиляются велосипеды с -W -Wall -Werror -Wextra!

Char в x86 размером 1 байт

чего это я вдруг тупой, вот массив:

char *card_symbols[] = {"\u2660","\u2663","\u2665","\u2666"};

int main(void)
{
int a = 0;
printf(«%d\n», a);
int b = 1;
printf(«%d\n», b);
return 0;
}

printf(«%d\n», a);
int b = 1;

да ты же и так пишешь на C99.

Да, мне это уже пояснили :)

Я использую, потому что бесплатного драфта С11 после принятия стандарта ещё нет.

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

а c99 это массивы переменной длины и однострочные комментарии

Комментарии и раньше можно было. А за массивы переменной длины убиват надо!

Вот записи вроде for(int x = 0; x < y; x++) удобны, да. И еще, наверное, кое-какие плюшки есть, но я их не использую.

Что Вы думаете по поводу использования этого стандарта? Стоит ли его использовать? И использует ли кто либо вообще.

Нет, вы что, сидите до конца жизни на C89. Вообще-то, все уже давно используют C11.

Я понял, но ещё раз скажу, что не с потолка это взял. Спасибо, заодно прояснилось что и динамические массивы зло.

А за массивы переменной длины убиват надо!

А что с ними не так?

P.S. /me не программист, так - хэллоувордщик

У меня по дефолту стоит компиляция с ключем C11. Xcode. Да, используют и ещё как, c89 - прошлый век :)

C11 - тоже. Он не самостоятелен, это фактически отпрыск работы над C++11.

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

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

чтоб не тянуть libstdc++ например

Например, чтобы писать расширения для Python, модули для Objective-C, Swift.

а можешь сходу назвать хоть одно отличие между C89 и C11? )

Да. Добавлены thread'ы. Можно в заголовке цикла for создавать переменную счётчика, к примеру:

 for (int counter = 0;

это можно и на крестах с extern «C»

Тебе уже сколько раз говорили, что если хочешь хрюникод, то пиши всякие извращения вроде wchar?

Очень вредный совет, wchar не нужен вовсе.

Для работы с юникодом в си используется либо char, либо libunistring/libicu и т д.

Его итак можно не тянуть.

Модули для питона можно писать на плюсах. Существует Objective-C++. Вот за swift не скажу.

Забавно, что оба твоих примера являются так же примером заимствования из C++. Казалось бы, почему просто не воспользоваться крестами сразу?

можно, если велосипедить свой stl, впрочем, с С его тоже придётся в той или иной форме.

Потому, что сейчас уже есть D и Go. Я вместо extern C в крестах - лучше то же самое напишу в D. Язык грамотнее, проще, удобнее. Имхо, сейчас писать на крестах смысла нет. На Objective-C - есть, на Go - тоже. Кресты вообще ничем не привлекают. Даже Java 8 и то интереснее.

Модули для питона как и сам питон пишутся на си. Ковырять кресты с обёртками для этого мне ну совсем не интересно. По мне так уж лучше писать расширения для питона на Objective-C/Swift. И то прикольнее.

А ты подумай, чем плохи массивы на стеке.

Посмотрю я, как ты будешь strlen на хрюникодовском char* делать...

D слишком маргинальный. Go слишком высокоуровневый из-за GC и сопутствующих вещей. Objective-C по сути язык под одну платформу. В общем ни один из них С++ полноценно заменить не может.

как ты будешь strlen на хрюникодовском char* делать

А какова должна быть семантика такого strlen?

очевидно что он как бы намекает на подсчёт количества code point-ов чтобы показать всю боль UTF-8, однако, большинство программ обходятся тупой побайтовой длиной

Посчитать codepoint-ы — это тоже хрень:

size_t utf8_strcodepoints (const char* ptr)
{
    size_t ret = 0;
    while (*ptr) {
        if (*ptr < 0x80 || *ptr > 0xBF)
            ++ret;
        ++ptr;
    }
    return ret;
}

Всё дело в том, что подсчёт количества codepoint-ов, подсчёт количества знакомест и подсчёт количества байт — задачи совершенно разные. При этом первая (если подумать) не имеет практического смысла, вторая не имеет смысла для немоноширинных шрифтов, а третья выполняется обычным strlen-ом.

Отсюда и вопрос: а чего он, собственно, хочет получить?

При этом первая (если подумать) не имеет практического смысла

По моему как раз все кладут на композитные символы и нормализацию :)

Угадай в каких единицах измерения число 10

create table foo(bar varchar(10) primary key)

ты в 32 бита закладываешься или в 64?