Это вызвало столько боли, что идея была заброшена.
большая часть кода на С легко собирается им же после «косметических» правок
Если этот код придерживается обшего подмножества Си и Си++. Посмотрю я, какие «косметические правки» потребуются работе с комплексными числами или VLA.
Это вызвало столько боли, что идея была заброшена.
ага, а еще использование стандарта С у них тоже вызвало много боли и в итоге С как он есть был заброшен
потребуются работе с комплексными числами или VLA.
а что там трудного то? тот же VLA прекрасно создается через alloca, и не надо говорить про стандарты - большая часть кода на С пестрит #ifdef на предмет подключения нестандартных хедеров, если же хочется стандарта - есть vector
твой пример кстати не соберется даже clang, даже с -std=c99, да и мало кто вообще так пишет, а так - да, придется сделать нетривиально и менее удобно/красиво:
void foo(void *pkt, int n)
{
struct {
int* head() { return pkt_;}
int* body() { return head()+1;}
int* tail() { return body()+n_;}
int *pkt_, n_;
} parsed_pkt = { (int*) pkt, n };
for (int i = 0; i < n; i++)
printf("%d\n", *parsed_pkt.tail());
}
но не соберется clang, msvc и пр., сам С конечно ни в чем не виноват, это так - к вопросу о совместимости, которая к сожалению не такая, как хотелось бы
Вот именно. А если структура будет более развесистой, получится еще неудобнее.
попасть в реальном коде на такое крайне маловероятно, ну и если говорить о реальных задачах - такой код можно и оставить на С, а новый писать с Protocol Buffers, например, это более универсальное решение
Да, и про _Complex не забываем - там тоже будет весело.
оно даже не обязательно к реализации - т.е. считай, что его и нет, да и проблем с переносом на С++ я не вижу, хотя конечно придется руками править
попасть в реальном коде на такое крайне маловероятно, ну и если говорить о реальных задачах - такой код можно и оставить на С, а новый писать с Protocol Buffers
Это не работа с сетью. Формат жестко задан железом.
Да, и про _Complex не забываем - там тоже будет весело.
оно даже не обязательно к реализации
Что-то я не вижу в стандарте указаний на необязательность.
«Complex types are a conditional feature that implementations need not support» - из драфта
У меня такой фразы нет. Но есть:
«A strictly conforming program shall use only those features of the language and library specified in this International Standard».
И комплексная арифметика описана именно в стандарте, не в аннексе.
«A conforming hosted implementation shall accept any strictly conforming program. A conforming freestanding implementation shall accept any strictly conforming program that does not use complex types [...]».
Т.е. hosted implementation должна поддерживать комплексную арифметику.
с чего вы решили, что я вообще что-то форматировал. у меня не моноширинный шрифт в окне ввода вообще-то. на глаз потыкал пробелов, оказались лишними. ну и пофиг, речь шла о «малой правке». эту же правку можно обернуть в «структуру» с accessorами, которая будет делать то же самое - но зачем?
A strictly conforming program can use conditional features (see 6.10.8.3) provided the use is guarded by an appropriate conditional inclusion preprocessing directive using the related macro. For example:
#ifdef _ _STDC_IEC_559_ _ /* FE_UPWARD defined */
/* ... */
fesetround(FE_UPWARD);
/* ... */
#endif