Здравствуйте, netch80, Вы писали:
V>>Через макросы и библиотеки можно сделать и сейчас в таком же предложенном синтаксисе, не факт что надо было тащить в стандарт.
N>В стандарт — чтобы все одинаково сделали. Это как раз полезно.
Ну если только в стандарт библиотеки, а не синтаксиса языка.
FR>>>Type-generic expressions using the _Generic keyword V>>Хм... шаблоны С++, ИМХО, мощнее, не факт что нужно было вводить это в С.
N>Введено именно затем, чтобы не вводить шаблоны.
Да просто я продолжаю смотреть на С с той точки зрения, чтобы его код можно было переносить в случае необходимости на С++ без полной переделки. И вот этот _Generic резко напрягает.
Здравствуйте, Mr.Cat, Вы писали:
N>>Кошмар какой-то пишешь. Зачем делать LISP внутри C, когда можно написать интерпретатор и конструкция будет значительно прямее? MC>Думаю, наш коллега недоволен макросами в Си и хочет, чтобы они были помощнее — что-нибудь навроде макросов в лиспе/схеме. Я так понимаю, макросы в си используются достаточно активно — было бы логично уделить внимание удобству часто используемого инструмента.
И какая религия мешает пропустить текст через любой нужный препроцессор?:) Генерируй себе из любых макросов, проблем-то...
Потому и не вводится ничего вместо стандартного препроцессора, что стандартный заточен на задачу, которая нужна в 100% случаев — а именно, поддерживать заголовочные файлы. А всё остальное — "твори, выдумывай, пробуй!" (tm) и не забудить применить make (в общем смысле), чтобы реализовать зависимости.
MC>Как-то на рсдн обсуждалась вот эта ссылка: http://voodoo-slide.blogspot.com/2010/01/amplifying-c.html. Там авторы вообще предлагают закатать весь си в лиспоскобки (что, конечно, уж слишком), но заодно и показывают, где бы нашли применение лиспомакросы (бойлерплейт, навроде корректного освобождения ресурсов, компайл-тайм проверки для функций а-ля принтф и т.п.)
Пусть выпустят макропроцессор, комплекты стандартных макросов и наберут хоть какую-то, но базу применений. Без этого их предложение никто всерьёз не рассмотрит.
Здравствуйте, alzt, Вы писали:
A>Сейчас ниша Си — это различные низкоуровневые приложения: операционные сети, драйвера, всевозможные контроллеры, мелкие утилиты, работа с памятью. A>Очень важным для Си на мой взгляд являются 2 вещи: A>1. указатели с адресной арифметикой, позволяющие сделать очень многие вещи
Есть в С++ A>и A>2. простота языка, что облегчает создание нового Си-компилятора.
A>Появился какой-нибудь хитроумный прибор с нестандартной архитектурой, для которого нужен драйвер. На чём его писать? Си отличный выбор. Во-первых, много программистов знает этот язык, т.к. их легко будет найти и заменить. Во-вторых, несложно сделать\адаптировать компилятор на Си для этого устройства. А часто и не надо этого делать, т.к. уже есть.
Писать с нуля компилятор для хитроумного прибора — бред. Портирование GCC с любой похожей архитектуры — пара-тройка человеко-месяцев (был личный опыт). Портируется только back-end, т.е. поддерживаться будут как C, так и C++ (без STL).
A>А если добавлять в язык множество фишек, то получится очередной Си++, т.к. джавы очевидно из Си уже не выйдет. Кто будет на нём писать? Для большинства приложений подойдут другие языки, которые и легче и первоначально предназначались для высокоуровневых задач.
ИМХО, допиливать C, когда есть C++ — полный бред. Зачем добавлять нативную поддержку unicode в C, если можно скомпилировать существующую программу на C компилятором C++, и в ней будет работать юникод? Победить панический страх некоторых разработчиков перед расширением CPP?
Берем существующий компилятор С++, собираем на нем нашу программу на С. Если нужны фичи из списка, используем СУЩЕСТВУЮЩИЕ фичи С++ (использование g++ вместо gcc не заставляет использовать исключения вместо кодов возврата):
FR>Из интересного:
FR>Multithreading support
FR>Type-generic expressions using the _Generic keyword
template<>
FR>Объявление переменных как и в C++ не в начале блока.
А вот эту фичу нельзя было добавлять. Никто из фанатов C этим языком теперь пользоваться не будет, т.к. это же перегружает компилятор...
Вообще, странная идея "возьмем очередное мелкое подмножество С++, обзовем его C с классами и прибамбасами, чтобы сишники не плевались, добавим пару ключевых слов, чтобы не пугать людей словом template и назовем это новым стандартом". Детский сад, короче.
FR>>Объявление переменных как и в C++ не в начале блока. П>А вот эту фичу нельзя было добавлять. Никто из фанатов C этим языком теперь пользоваться не будет, т.к. это же перегружает компилятор...
Здравствуйте, SpaceConscience, Вы писали:
FR>>>Объявление переменных как и в C++ не в начале блока. П>>А вот эту фичу нельзя было добавлять. Никто из фанатов C этим языком теперь пользоваться не будет, т.к. это же перегружает компилятор...
SC>Это старая фича из C99.
Да знаю-знаю. Не удержался, решил съязвить...
Здравствуйте, netch80, Вы писали: N>Потому и не вводится ничего вместо стандартного препроцессора
А по мне так _generic с явным прицелом на макросы предлагается.
N>Пусть выпустят макропроцессор, комплекты стандартных макросов и наберут хоть какую-то, но базу применений. Без этого их предложение никто всерьёз не рассмотрит.
А у них есть препроцессор на базе коммонлиспа: http://gitorious.org/c-amplify/
Здравствуйте, пыщьх, Вы писали:
П>ИМХО, допиливать C, когда есть C++ — полный бред. Зачем добавлять нативную поддержку unicode в C, если можно скомпилировать существующую программу на C компилятором C++, и в ней будет работать юникод? Победить панический страх некоторых разработчиков перед расширением CPP?
Потому что существует куча людей, которые сознательно выбирают Си для своего нового кода, и не хотят платить цену C++, не используя никаких его преимуществ.
Pzz>Потому что существует куча людей, которые сознательно выбирают Си для своего нового кода, и не хотят платить цену C++, не используя никаких его преимуществ.
О, а что, за использование C++ надо платить? Комитету? И вы платите? Странно, я никогда не платил и не слышал, чтобы кто-нибудь платил.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, пыщьх, Вы писали:
П>>ИМХО, допиливать C, когда есть C++ — полный бред. Зачем добавлять нативную поддержку unicode в C, если можно скомпилировать существующую программу на C компилятором C++, и в ней будет работать юникод? Победить панический страх некоторых разработчиков перед расширением CPP?
Pzz>Потому что существует куча людей, которые сознательно выбирают Си для своего нового кода, и не хотят платить цену C++, не используя никаких его преимуществ.
И какова цена C++, компилирующего исходники на чистом C (с парой фич С++)?
Здравствуйте, пыщьх, Вы писали:
Pzz>>Потому что существует куча людей, которые сознательно выбирают Си для своего нового кода, и не хотят платить цену C++, не используя никаких его преимуществ. П>И какова цена C++, компилирующего исходники на чистом C (с парой фич С++)?
Время компиляции, неполная совместимость с Си (особенно раздражает необходимость явно преобразовывать void*), некоторые фичи C++, типа исключений, имеют свою цену в генерируемом годе, даже если их не использовать, отсутствие предупреждений о несовместимости исходного кода с Си (что может быть важным, если предполагается портабельность этого кода), и т.д. и т.п.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, пыщьх, Вы писали:
Pzz>Время компиляции
Убогое время компиляции в C/C++ связано не с фичами языка, а с допотопной моделью компиляции с отдельным этапом препроцессинга, кучей подключаемых хедеров, объектников и .lib'ов. Естественно, если вы на голых сях напишете программу только с #include <stdio.h>, то она будет компилироваться заметно быстрее, чем плюсплюсовая, в которой подключена добрая половина boost'а. Однако сравнение некорректно в том плане, что подключенные в первом случае библиотеки дают гораздо меньше функционала, чем подключенные во втором — так что тут имеет место tradeoff, а не однозначный проигрыш.
Pzz>неполная совместимость с Си (особенно раздражает необходимость явно преобразовывать void*)
В C++ нет необходимости приводить void* к чему-либо, поскольку malloc() в нём есть лишь для обратной совместимости, а не как рекомендуемый способ выделения памяти. Use new, Luke!
Pzz> некоторые фичи C++, типа исключений, имеют свою цену в генерируемом годе, даже если их не использовать
Сроду не требовалось платить за то, что не используешь.
Pzz> отсутствие предупреждений о несовместимости исходного кода с Си (что может быть важным, если предполагается портабельность этого кода), и т.д. и т.п.
А зачем компилятору одного языка заботиться о совместимости с другим? C++ — это всё-таки другая парадигма программирования а не просто ООП-расширение для старого доброго C. Соответственно, в нём всегда рекомендовалось, например, использовать cout << foo << endl; вместо printf("%d\n", foo);. Таким образом, имея файл с расширением .cpp, не стоит ожидать его совместимости с .c. Если нужно кровь из носа иметь в некотором проекте куски, компилируемые на обоих языках, их можно явно компилировать как C-код. Либо (для любителей потрахаться) добавить в процесс отдельный шаг с компиляцией тем компилятором C, совместимость с которым требуется — исключительно для проверки.
Здравствуйте, MaxSem, Вы писали:
MS>Убогое время компиляции в C/C++ связано не с фичами языка, а с допотопной моделью компиляции с отдельным этапом препроцессинга, кучей подключаемых хедеров, объектников и .lib'ов. Естественно, если вы на голых сях напишете программу только с #include <stdio.h>, то она будет компилироваться заметно быстрее, чем плюсплюсовая, в которой подключена добрая половина boost'а. Однако сравнение некорректно в том плане, что подключенные в первом случае библиотеки дают гораздо меньше функционала, чем подключенные во втором — так что тут имеет место tradeoff, а не однозначный проигрыш.
Я сравнивал время компиляции одного и того же текста, с одними и теми же #include. Результат чуть выше по thread'у, разница в несколько раз. Угадайте, в чью пользу
Pzz>>неполная совместимость с Си (особенно раздражает необходимость явно преобразовывать void*)
MS>В C++ нет необходимости приводить void* к чему-либо, поскольку malloc() в нём есть лишь для обратной совместимости, а не как рекомендуемый способ выделения памяти. Use new, Luke!
Минуточку, минуточку. Мне тут впаривают компилятор C++ в качестве компилятора Си, только лучше. Какой нафиг use new? В Си нет никакого new.
Pzz>> некоторые фичи C++, типа исключений, имеют свою цену в генерируемом годе, даже если их не использовать
Pzz>> отсутствие предупреждений о несовместимости исходного кода с Си (что может быть важным, если предполагается портабельность этого кода), и т.д. и т.п. MS>А зачем компилятору одного языка заботиться о совместимости с другим? C++ — это всё-таки другая парадигма программирования а не просто ООП-расширение для старого доброго C. Соответственно, в нём всегда рекомендовалось, например, использовать cout << foo << endl; вместо printf("%d\n", foo);. Таким образом, имея файл с расширением .cpp, не стоит ожидать его совместимости с .c. Если нужно кровь из носа иметь в некотором проекте куски, компилируемые на обоих языках, их можно явно компилировать как C-код. Либо (для любителей потрахаться) добавить в процесс отдельный шаг с компиляцией тем компилятором C, совместимость с которым требуется — исключительно для проверки.
Парой мессаджей выше звучало утверждение, что незачем, мол, поддерживать Си, если есть C++, который и Си компилирует, и все новые расширения поддерживает, и разве что лапти не штопает. Вот затем и надо, что C++ — не Си, хоть свиду и похож.
Здравствуйте, Pzz, Вы писали:
Pzz>Время компиляции,
Для embedded и т.п. (где Си обычно и используется) — несущественно, ибо 1 сек vs. 2 сек. Pzz>неполная совместимость с Си (особенно раздражает необходимость явно преобразовывать void*)
80% преобразований void * — это malloc(). Вместо него в C++ есть new(). Остальные 20% легко лечатся использованием template<>. В любом случае, несильно причесать код, ИМХО, намного проще, чем создавать новый стандарт и переводить на него компиляторы. Pzz>некоторые фичи C++, типа исключений, имеют свою цену в генерируемом годе, даже если их не использовать,
Not really. По крайней мере, в GCC и MSVC, C-шный файл, собранный C++-компилятором будет идентичен собранному C-шным компилятором (после линковки и убиения debug info). Pzz>отсутствие предупреждений о несовместимости исходного кода с Си (что может быть важным, если предполагается портабельность этого кода), и т.д. и т.п.
Очевидно, если мы используем фичи С++, то код будет несовместим с Си. Зачем тогда предупреждения? Собираем C-шным компилятором и получаем список ошибок.
Здравствуйте, пыщьх, Вы писали:
Pzz>>Время компиляции, П>Для embedded и т.п. (где Си обычно и используется) — несущественно, ибо 1 сек vs. 2 сек.
С чего это вы взяли? Си используется во всех тех же областях, где и другие языки общего назначения.
Pzz>>неполная совместимость с Си (особенно раздражает необходимость явно преобразовывать void*) П>80% преобразований void * — это malloc(). Вместо него в C++ есть new(). Остальные 20% легко лечатся использованием template<>. В любом случае, несильно причесать код, ИМХО, намного проще, чем создавать новый стандарт и переводить на него компиляторы.
Спасибо. И потерять при этом обратную совместимость с сишными компиляторами?
Pzz>>отсутствие предупреждений о несовместимости исходного кода с Си (что может быть важным, если предполагается портабельность этого кода), и т.д. и т.п. П>Очевидно, если мы используем фичи С++, то код будет несовместим с Си. Зачем тогда предупреждения? Собираем C-шным компилятором и получаем список ошибок.