Написание кода на C, совместимом с C++

ISO-IEC 14882-2014. Information technology - Programming languages - C++, Annex C1.

Они за текст стандарта деньги хотят

Будь выше их, скачай так.

Они за текст стандарта деньги хотят

Последний драфт должен быть доступен бесплатно.

Да, драфт я нашел какой-то http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3690.pdf

Только там непонятно, с какой конкретно версией стандарта C идет сравнение совместимости

This subclause lists the differences between C++ and ISO C, by the chapters of this document

Например в новых стандартах C есть массивы, размер которых можно задать через переменную, при этом программа выделит нужное место на стеке. В плюсах этого нет

int char[a];

Вот неплохой список различий: http://david.tribble.com/text/cdiffs.htm

Суть в том, что стандарты 2011 и 2014 ссылаются на С99. С++11 вышел раньше С11, а С++14 - мелкий релиз, куда такого не совали.

Массивы переменной длины(variable-length arrays) были введены еще в C99

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

в чем проблема добавить в заголовки extern «C» и использовать код как сишный?

Мне кажется, месье читер.

В том что например for (int i=0; i <0; i++) не осилит C компиллер, он скажет объявите i отдельно. И таких ньюансов полно.

И в соответствии с какой версией стандарта С это будет компилироваться? К тому же прочитай ОП-пост. Там написано

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

Дополнить плюсовой фигней код, заключенный в extern C уже не выйдет

В том что например for (int i=0; i <0; i++) не осилит C компиллер, он скажет объявите i отдельно. И таких ньюансов полно.

-std=gnu99 точно решает эту проблему для си.

А вообще в крайнем случае ifdef-ами разделаться.

Дополнить плюсовой фигней код, заключенный в extern C уже не выйдет

Дык не надо смешивать сишный код с плюсовой фигней, ее можно сверху обернуть

Массивы переменной длины(variable-length arrays) были введены еще в C99

Интересно, смахивает на упущение стандарта. Кстати в С11 они есть только если _ _STDC_NO_VLA_ _ не определен, хотя в С99 были безусловно.

В том что например for (int i=0; i <0; i++) не осилит C компиллер

Это давно уже в c99

Беглый просмотр Annex C1 из драфта не выявил указания, что такая фича в плюсах отсутствует

Ну так она там как раз присутствует.

Откуда? Компилируй с опцией -pedantic

warning: variable length arrays are a C99 feature [-Wvla-extension]

Какому стандарту С должен соответствовать код, засунутый в extern «C» { ?

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

смахивает на упущение стандарта

Насколько мне известно, VLA не были добавлены в C++ умышленно. И правильно, нечего всякий бред тянуть, начиная с C99 разработка языка явно пошла под какими-то суровыми веществами.

С++. extern «C» просто отключает декорацию имён, он не имеет никакого отношения к тому, что за этими именами скрывается.

В том что например for (int i=0; i <0; i++) не осилит C компиллер

... не осилит, если не умеет в C99.

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

он ещё включает передачу параметров только через стек и в определённом «сишном» порядке.

Насколько мне известно, VLA не были добавлены в C++ умышленно. И правильно, нечего всякий бред тянуть, начиная с C99 разработка языка явно пошла под какими-то суровыми веществами.

Причем тут VLA? Я говорю про упущение описания разницы в Annex C1.

Как выделить на стеке неизвестно какое количество байт одним куском?

Никак, да и нефиг. Реализация VLA возможна не для всех платформ, потому и нефиг ее в язык пихать. А проблем у VLA хватает - типа stack overflow без возможности обработки (сходу имеешь способ DOS атак).

Реализация VLA возможна не для всех платформ

А для каких платформ она невозможна? Не вижу никаких проблем в написании аналога VLA вручную на языках ассемблера (например на известных мне i8080, x86-32, x86-64, ARM).

Только там непонятно, с какой конкретно версией стандарта C идет сравнение совместимости

См. список Normative References на стр. 1 (арабская, стр. 16 по счёту с начала). C99.

Например в новых стандартах C есть массивы, размер которых можно задать через переменную, при этом программа выделит нужное место на стеке. В плюсах этого нет

В черновике, который ты читаешь, VLA есть, см. стр. 185 (200 по счёту с начала). Из финальной версии стандарта они были удалены.

В более новом черновике VLA уже нет http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf стр. 212

Тем не менее там в Annex C1 не написано про отсутствие в плюсах VLA. Где скачать финальный стандарт плюсов не за деньги я не нашел

он ещё включает передачу параметров только через стек и в определённом «сишном» порядке.

Глупости. Это зависит от реализаци (ABI) и обычно CC для С и С++ ф-ий одинаковые.

А проблем у VLA хватает - типа stack overflow без возможности обработки

Эта проблема существует и для обычных массивов с константным размером. VLA тут ничего нового не добавляют.

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

Самый грамотный ответ, топик можно закрывать. Нет, правда.

Эта проблема существует и для обычных массивов с константным размером. VLA тут ничего нового не добавляют.

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

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

Тем не менее там в Annex C1 не написано про отсутствие в плюсах VLA

VLA в Си++ нет.

Не вижу никаких проблем в написании аналога VLA вручную на языках ассемблера

Не видь дальше, но именно из-за этого его и выпилили как обязательную фичу.

Еще как добавляют ... А с VLA можно приложение грохнуть.

Ну расскажи уж тогда как можешь грохнуть его с VLA так чтобы нельзя было аналогично сделать на обычных массивах.

так чтобы нельзя было аналогично сделать на обычных массивах

Если ты не понял, VLA - функциональный аналог массива в куче, а не стекового.

VLA - функциональный аналог массива в куче, а не стекового

Херасе.

Если ты не понял, VLA - функциональный аналог массива в куче, а не стекового.

Какая разница как ты для себя определяешь VLA, покажи просто пример.

Очевидно же:

#include <stdio.h>

int main()
{
    int len;
    scanf("%d", &len); // вводим 2000000

    double big[len];

    for (int i = 0; i < len; i++)
    {
        big[i] = 0;
    }
}

Обычными массивами можно связный список нужного размера на стеке выделить через рекурсию, но это будет жуткий костыль и говнокод. А так вообще, очевидная альтернатива(аналог) VLA - alloca()

Я тут еще подумал. Через определенные костыли можно и без alloca() сделать аналог VLA на C, но это будет уже полный аут

Очевидно же...

Этот пример неправильный, аналогично можно сделать с массивом константного размера, это не особенность VLA.

С99 осилит

у компиляторов для разных языков разные методы формирования и передачи параметров. и это не обязательно С/C++. обычно компилятор предоставляет несколько вариантов, для совместимости с другими языками и cdecl - один из самых распространённых и принятых для взаимодействия модулей, написанных на разных языках.

у компиляторов для разных языков разные методы формирования и передачи параметров. и это не обязательно С/C++

СС не является частью C/C++, это платформозависимо. cdecl это не обязательный CC для С кода, потому и extern «C» по факту незачем делать CC отличным от C++ вызовов. Нужно ли ещё раз объяснять это другими словами?

... и cdecl - один из самых распространённых и принятых для взаимодействия модулей, написанных на разных языках.

Это было на x86_32 платформах, сейчас (на amd64, армах и т.д. в онтопиках) cdecl давно уже не используется. С разморозкой.

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