Чего Вам не хватает в С ?

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

 

что-то фантазия разыгралась...
ладно, списки и паттерн матчинг по ним - это слишком уже, это непрозрачно. а вот HOF - это было бы неплохо, тем более, если у нас уже нафантазирован вывод типов.
кстати, более симпатичный интерфейс описания типов функций не помешал бы. нынешний выглядит довольно страшно в сравнении с более простыми аналогами(скажем, Haskell).

обобщенные функции - это гуд, однозначно. возможно, для них какие-то спецификаторы типа тайпклассов(которые для меня темный лес, мог случайно не туда приплести =) ) или так и не появившихся в С++0х концептов.

вспоминая про стандартную библиотеку - очень не помешали бы pascal-style строки, прям совсем не помешали бы. опционально - проверка границ массивов в целом, отключаемая, естественно.

классы/интерфейсы/etc - сложный вопрос, могут ли они быть достаточно прозрачными. потому, ну их нафиг. да и зачем они, если у нас уже нафантазировано все предыдущее? =)

 

С некоторой натяжкой, функции высших порядков (HOF) в С++ есть, например for_each. pascal-style это std::string, проверка границ массивов есть в std::vector<> & std::array<>. На С++ можно писать и чистые функции, и даже компилировать LISP.

 

ну списки и прочиеи adt вместе с паскаль строками это все есть я например юзаю glib там и динамические строки и контейнеры всевозможные чего только нет надо то только подключить заголовочный файл . Проверка границ у массивов даже и не вспомню чтоб так часто надо было работать с голыми массивами обычно теже списки или на худой конец malloc realloc когда под рукой ничего нет настоящая жесть это строки но можно юзать GString из glib вполне себе динамические строки
а вообще что еще так это после всех этих динамических структур при выходе надо вызывать destroy функции явно в результате или прыгать по goto в одно место где все освободждается или после каждого if'а копипастить код механизм бы такой чтоб при выходе из функции вызывались автоматически destroy функции )

 

Черыне знака препинания на 773 символа это жесть. При том что три из них составляют смайл.
По поводу последней части предложения, есть auto_ptr.

 

итого нормальный механизм освобождения ресурсов а все остальное в библиотеках есть gstring glist gtree garray etc ...
чтоб можно было выходить из функции не прыгая на метку с destroy функциями а так просто при любом чихе все динамические объекты созданные внутри разрушались бы )
но все равно работа с winapi требовала бы закрывать всякие хендлы тогда бы ее пришлось и ее переделать чтоб файл и прочие сущности были динамическими и при выходе тоже закрывались разрушались )) что то я такое представил далекое от Си )))

 

osox не такое и далекое представил, может даже большинство С кода компилировать без изменений, называется С++ Для автоматического освобождения ресурсов придумана идиома RAII.

 

Всю поддержку complex. И safe-функции из грядущего стандарта.

 

iZzz32
просто не юзайте их, в чем проблема?
это же библиотеки, а не синтаксис языка

 

ADT != ADT. я имел ввиду, естественно, первые. и вообще, мы говорим о языке и стандартной библиотеке, а не о внешних типа glib.

 

GoldFinch, я компилятор пишу.

 

J0E
да RAII это очень удобно а есть какие нибудь подводные камни с ней ?

 

К RAII быстро привыкаешь и потом тяжело писать на С Вообще есть одна проблема, не совсем с RAII, но с умными указателями типа shared_ptr, когда 2 объекта ссылаются друг на друга, возникает циклическая зависимость и объекты не удаляются.

 

это проблема не RAII, а проблема объектов с подсчетом ссылок, в любом языке.

 

Проблему с перекрестными ссылками решает сборщик мусора. А RAII в принципе тоже на подсчете ссылок основан, но обычно считает до 1й )

 

J0E

Я не экономлю буквы вообще. Экономить буквы, знаки препинания или 50 копеек на пластиковом пакете - плебейство и нищебродство. Я это презираю. Просто отсутствие break компилятор ошибкой вообще не считает, хотя на самом деле в 99% случаев это так.

Voodoo

А также динамические массивы с возможностью использовать начальный индекс массива, отличный от нуля. А то на каждый чих хвататься за std::vector как-то вообще не кавайно, а С++ Builder, к сожалению, единственный компилятор, где это есть.

 

Перед тем, как бросаться разными гнусными словами и цифрами, давай проведем эксперимент. Только без подтасовок. Вот прям сейчас, в тех проектах которые у тебя УЖЕ открыты, посчитай количество switch. Я это уже проделал:

9 MLOC С -- ~16500 switch

88 KLOC С++ -- 26 switch из котрых 2 в комментарии

В 3м проекте считать не буду, не умею тем редактором пользоваться.

Резюме я тоже уже составил: ты думешь не о проблемах.

 

green

Ну и в чём проблема? Слова "файл" и "поток" склоняются одинаково. Нада знать рускава езыка. А во-вторых, зачем в практической программе такие понты? Чтобы поддерживать было геморройнее? Первый же год профессиональной деятельности из "хаккиров" очень эффективно выбивает желание использовать хитровытраханные конструкции и учит писать "квадратиш, практиш, гут". После чего они как миленькие начинают творить в духе if (p==NULL) {один_сцуко_оператор;} Ибо это сегодня там один_сцуко_оператор, а когда задачу поменяют в пятый раз, там этих операторов будет уже по самый анус, а после долгого застолья, перетекшего в бессонную ночь, людям думать вломы, а уж о всякой чухне типа скобочек - ваще вломы. Проще сразу нарисовать.

 

CyberManiac

См. пост #154

Генерация имени идентификатора препроцессором - довольно типичная конструкция. Например, очень плотно используется в библиотеках вроде CRT, MFC или ATL. В исходниках ядра Linux этого добра тоже дофига. Там что понтами это никак нельзя назвать.
Если в С++ необходимость такого подхода частично снимается шаблонами (для идентификаторов типов и ф-ций), то в С - это единственная возможность для параметризации идентификатора.

 

Expert C Programming, Deep C Secrets