Почему никто не обновляет свой компилятор C расширенными функциями?

Question

struct elem
{
 int i;
 char k;
};
elem user; // compile error!
struct elem user; // this is correct

В приведенном выше фрагменте кода мы получаем ошибку для первого объявления. Но эта ошибка не возникает с компилятором C ++. В C ++ нам не нужно снова и снова использовать ключевое слово struct.

Так почему никто не обновляет свой компилятор C, чтобы мы могли использовать структуру без ключевого слова, как в C ++?

Почему разработчик компилятора C не устраняет некоторые сбои C, такие как приведенный выше, и не обновляет некоторые расширенные функции, не нарушая первоначальную концепцию C?

Почему это тот же старый компилятор, не обновленный с 1970-х годов?

Посмотрите на visual studio и т. Д. Он часто обновляется новыми выпусками, и для каждого нового выпуска мы должны изучать использование некоторых новых функций (даже если это проблема, с которой мы можем справиться). Мы также получим обновление с новым компилятором, если таковой имеется.

Не воспринимайте это как глупый вопрос. Почему это не возможно? Он может быть разработан без каких-либо проблем несовместимости (не затрагивая код, который был разработан на нынешнем / старом компиляторе)

Хорошо, давайте разработаем новый язык C, C +, который находится между C и C ++, который устраняет все недостатки C и добавляет некоторые расширенные функции из C ++, сохраняя его полезным для конкретных приложений, таких как приложения системного уровня, встроенные системы и т. Д.

Answer 1

Потому что для развития нового стандарта требуются годы. Они работают над новым стандартом C ++ ( C ++ 0x ), а также над новым стандартом C (C1x), но если вы помните, что для каждой итерации обычно требуется от 5 до 10 лет, я не ожидайте увидеть его до 2010 года или около того.

Кроме того, как и в любой демократии, в Стандарте есть компромиссы. У вас есть сторонники жесткой линии, которые говорят: «Если вы хотите всего этого необычного синтаксического сахара, выберите игрушечный язык, такой как Java или C #, который берет вас за руку и даже покупает леденец на палочке», тогда как другие говорят: «Язык должен быть проще и меньше подвержен ошибкам, чтобы выжить в наши дни или быстро сокращать циклы разработки ".

Обе стороны частично правы, поэтому стандартизация - это очень долгая битва, которая займет годы и приведет ко многим компромиссам. Это относится ко всему, где участвуют несколько крупных партий, это касается не только C / C ++.

Answer 2

typedef struct
{
 int i;
 char k;
} elem;

elem user;

будет хорошо работать. как уже говорилось, речь идет о стандарте - когда вы реализуете это в VS2008, вы не можете использовать его в GCC, а когда вы реализуете это даже в GCC, вы, конечно, не компилируете что-то еще. Метод выше будет работать везде.

С другой стороны - когда у нас есть стандарт C99 с типом bool, объявления в цикле for () и в середине блоков - почему бы и эта функция тоже не была?

Answer 3

Прежде всего, компиляторы должны поддерживать стандарт. Это правда, даже если стандарт кажется неловким задним числом. Во-вторых, поставщики компиляторов добавляют расширения. Например, многие компиляторы поддерживают это:

(char *) p += 100;

для перемещения указателя на 100 байтов вместо 100 любого типа p является указателем на. Строго говоря, это нестандартно, потому что приведение убирает lvalue-ness p.

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

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

Результат для разработчиков программного обеспечения заключается в том, что вам может потребоваться записать с наименьшим общим знаменателем, обычно ANSI C (C89). Например: Parrot, виртуальная машина, на которой будет работать следующая версия Perl, написана на языке ANSI C. Perl6 будет иметь чрезвычайно мощный и выразительный синтаксис с некоторыми изгибающими концепциями, встроенными прямо в язык. Реализация, однако, строится с использованием языка, который является почти полной противоположностью. Причина в том, что это позволит Perl работать где угодно: ПК, Mac, Windows, Linux, Unix, VAX, BSD ...

Answer 4

Я обнаружил, что когда я реализовал нестандартные расширения для C и C ++, даже когда люди их запрашивают, они не привыкли. Мир C и C ++ определенно вращается вокруг строгого соответствия стандартам. Многие из этих расширений и улучшений нашли благодатную почву в языке программирования D.

Вальтер Брайт, Цифровой Марс

Answer 5

Эта «особенность» никогда не будет принятой будущими стандартами C только по одной причине: она сильно нарушит обратную совместимость. В C теги struct имеют отдельные пространства имен для обычных идентификаторов, и это может или не может рассматриваться как функция. Таким образом, этот фрагмент:

struct elem
{
    int foo;
};

int elem;

Прекрасно в C, потому что эти два элемента находятся в разных пространствах имен. Если будущий стандарт позволит вам объявить struct elem без спецификатора структуры или соответствующего typedef, вышеприведенная программа завершится неудачно, потому что elem используется в качестве идентификатора для int.

Примером, когда будущий стандарт C фактически нарушает обратную совместимость, является случай, когда C99 запретил функцию без явного возвращаемого типа, то есть:

foo(void); /* declare a function foo that takes no parameters and returns an int */

Это незаконно в C99. Однако сделать этот C99-совместимым просто, добавив тип возвращаемого значения int. Не так просто «исправить» программы на C, если вдруг теги struct не имеют отдельного пространства имен.

Answer 6

Большинство людей, все еще использующих C, используют его, потому что они либо:

• Ориентация на очень конкретную платформу (т.е. встроенную) и, следовательно, должна использовать компилятор, предоставленный поставщиком этой платформы
• Озабоченность переносимостью, в этом случае нестандартный компилятор может победить цель
• Очень удобно с простым C и не вижу причин для изменений, в этом случае они просто не хотят.

Answer 7

Следующая программа выводит «1» при компиляции как стандартный C или что-то еще, возможно, 2, когда компилируется как C ++ или предложенный синтаксис Вот почему язык C не может сделать это изменение, это придаст новый смысл существующему коду. И это плохо!

#include <stdio.h>

typedef struct
{
    int a;
    int b;
} X;

int main(void)
{
    union X
    {
        int a;
        int b;
    };

    X x;
    x.a = 1;
    x.b = 2;

    printf("%d\n", x.a);

    return 0;
}

Answer 8

На самом деле, многие компиляторы C добавляют функции - разве почти каждый компилятор C не поддерживает стиль C ++ // комментарии?

Большинство функций, добавленных в обновления стандарта C (C99 является самым последним), получены из расширений, которые «завоевали популярность».

Например, хотя компилятор, который я сейчас использую на встраиваемой платформе, не претендует на соответствие стандарту C99 (и в нем немало отсутствует), он добавляет следующие расширения (все которые заимствованы из C ++ или C99) для поддержки «C90»:

• объявления, смешанные с заявлениями
• анонимные структуры и союзы
• встроенный
• объявление в выражении инициализации цикла
• и, конечно же, стиль C ++ // комментарии

Проблема, с которой я сталкиваюсь, заключается в том, что когда я пытаюсь скомпилировать эти файлы с помощью MSVC (либо для тестирования, либо потому, что код полезен не только для встроенной платформы), он подавится большинством из них (я я честно не уверен насчет анонимных структур / союзов).

Итак, расширения добавляются в компиляторы C, просто они выполняются с разной скоростью и по-разному (поэтому перенос кода с их использованием становится все труднее), и процесс переноса их в стандарт происходит на около ледникового темпа.

Answer 9

У нас есть typedef именно для этой цели. И, пожалуйста, не меняйте стандарт, у нас уже достаточно проблем с совместимостью ....

@ Manoj Doubts comment
У меня нет проблем с вами или кем-то еще, чтобы определить C + или C- или Cwh независимо, если вы не коснетесь C:)
Мне по-прежнему нужен язык, который мог бы выполнить мою задачу - иметь такой же код (не маленький), чтобы он мог работать на десятках операционных систем, скомпилированных значительным числом различных компиляторов, и иметь возможность для работы на десятках различных аппаратных платформ на данный момент есть только один язык, который позволяет мне выполнить мою задачу, и я предпочитаю не экспериментировать с этой способностью :) Особенно по той причине, которую вы предоставили. Вы действительно думаете, что умение писать

foo test;

вместо

struct foo test;

сделает код лучше с любой точки зрения?

Answer 10

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

struct elem
{
 int i;
 char k;
};
elem user;

скомпилирует?