Здравствуйте, FR, Вы писали:
FR>Из интересного:
FR>Multithreading support
Через макросы и библиотеки можно сделать и сейчас в таком же предложенном синтаксисе, не факт что надо было тащить в стандарт.
FR>Improved Unicode support
С юникодом круто, ибо поддержка синтаксиса. Особенно полезно, если char16_t будет другим типом, а не typedef к short. Было бы неплохо, если бы этот синтаксис так же поддерживался следующими стандартами С++.
FR>Type-generic expressions using the _Generic keyword
Хм... шаблоны С++, ИМХО, мощнее, не факт что нужно было вводить это в С.
Здравствуйте, SpaceConscience, Вы писали:
SC>Молодцы, вроде не стремятся к излишнему усложению.
SC>
SC>#define минимализм "убожество"
SC>
Сейчас ниша Си — это различные низкоуровневые приложения: операционные сети, драйвера, всевозможные контроллеры, мелкие утилиты, работа с памятью.
Очень важным для Си на мой взгляд являются 2 вещи:
1. указатели с адресной арифметикой, позволяющие сделать очень многие вещи
и
2. простота языка, что облегчает создание нового Си-компилятора.
Появился какой-нибудь хитроумный прибор с нестандартной архитектурой, для которого нужен драйвер. На чём его писать? Си отличный выбор. Во-первых, много программистов знает этот язык, т.к. их легко будет найти и заменить. Во-вторых, несложно сделать\адаптировать компилятор на Си для этого устройства. А часто и не надо этого делать, т.к. уже есть.
А если добавлять в язык множество фишек, то получится очередной Си++, т.к. джавы очевидно из Си уже не выйдет. Кто будет на нём писать? Для большинства приложений подойдут другие языки, которые и легче и первоначально предназначались для высокоуровневых задач.
У меня лично был опыт создания большой прикладной программы на чистом си. Да, такой адский мазохизм.
Для себя я решил, что си — это вообще не язык программирования, а формат объектных файлов. Он хорошо подходит только для конвертирования в него кода из нормального языка.
Лаконичность языка — это достоинство, недостаток в нем — это полная и абсолютная нерасширяемость. То есть в языке ничего нет, и добавить — никак. Хорошо, хоть есть препроцессор, хоть какое-то ничтожное метапрограммирование, а то без него было бы совсем уныло.
Простота создания компилятора — это стандартная отмазка. На самом деле, ядро языка можно было бы сделать еще проще, но достаточно сделать возможности для расширения и получить на порядок более мощный язык, см. лисп, например.
Плюс, есть еще такие понятия, как фронтенд и бэкенд. В норме, если у вас появился новый нестандартный процессор, надо написать бэкенд к GCC и программировать на C++. Что за дурь такая — каждый раз переписывать весь компилятор вместе с парсером под каждую новую платформу?
А что касается "низкоуровневости" — если посмотреть на реальные программы на си, мы там увидим суррогат объектного языка программирования с объектами, инкапсуляций и полиморфизмом, только реализовано все это вручную. В итоге средняя программа на си изоморфна аналогичной программе на C++, только в первой делается вручную то, что во второй делает компилятор.
Флейм разводить я не имел в виду, так как для меня и так все ясно.
Если кому-то нравится на си писать сложные программы — пускай пишут, есть же умельцы, которые могут одним топором церковь срубить.
Здравствуйте, alzt, Вы писали:
A>Появился какой-нибудь хитроумный прибор с нестандартной архитектурой, для которого нужен драйвер. На чём его писать? Си отличный выбор. Во-первых, много программистов знает этот язык, т.к. их легко будет найти и заменить. Во-вторых, несложно сделать\адаптировать компилятор на Си для этого устройства. А часто и не надо этого делать, т.к. уже есть.
Ну, строго говоря, сейчас задача переноса Си на новую архитектуру решается путем добавления backend'а к gcc и написания runtime library. А тем самым, почти автоматически решается задача переноса на нее всей группы языков, поддерживаемых gcc
Здравствуйте, dilmah, Вы писали:
D>Я недавно обнаружил, что типы нельзя определять в возращаемом типе, то есть нельзя писать типа такого:
Хм. gcc этот код съел. g++ — нет. Я не большой знаток тонкостей c++, но думаю дело в scope: если дозволить такое определение типа, то виден этот тип будет в единственном месте, в прототипе функции. А значит, им никак нельзя будет воспользоваться ни в самой функции, ни в коде, вызывающей ее, а потому такое определение бесполезно и попытка использования его — ошибочна.
Здравствуйте, SpaceConscience, Вы писали:
SC>У меня лично был опыт создания большой прикладной программы на чистом си. Да, такой адский мазохизм. SC>Для себя я решил, что си — это вообще не язык программирования, а формат объектных файлов. Он хорошо подходит только для конвертирования в него кода из нормального языка.
Давно есть уже более внятное определение — "переносимый ассемблер". Конечно, он при этом ни разу не язык высокого уровня (по современным меркам, а не 70-х годов). Ну и что с того? Ниши всякие нужны, роли всякие важны.
SC>Лаконичность языка — это достоинство, недостаток в нем — это полная и абсолютная нерасширяемость. То есть в языке ничего нет, и добавить — никак. Хорошо, хоть есть препроцессор, хоть какое-то ничтожное метапрограммирование, а то без него было бы совсем уныло.
Не говори "ничего нет" про тьюринг-полную систему.:) Всё, что нужно — можно написать. Почему ты решил писать напрямую на Си, а не на domain specific language, хотя бы и самопальном? Или на чём-то скриптовом? Бутербродное построение придумали много лет назад.
SC>Простота создания компилятора — это стандартная отмазка. На самом деле, ядро языка можно было бы сделать еще проще, но достаточно сделать возможности для расширения и получить на порядок более мощный язык, см. лисп, например.
Кошмар какой-то пишешь. Зачем делать LISP внутри C, когда можно написать интерпретатор и конструкция будет значительно прямее?
SC>Плюс, есть еще такие понятия, как фронтенд и бэкенд. В норме, если у вас появился новый нестандартный процессор, надо написать бэкенд к GCC и программировать на C++. Что за дурь такая — каждый раз переписывать весь компилятор вместе с парсером под каждую новую платформу?
Что за дурь такая — не читать документацию и считать, что "переписывать весь компилятор"? Для новой платформы надо её описать, это да. Описание делается стандартным образом и не меняет существующие механизмы. И зачем "программировать на C++"? Ты GCC с Clang/LLVM не путаешь?
SC>А что касается "низкоуровневости" — если посмотреть на реальные программы на си, мы там увидим суррогат объектного языка программирования с объектами, инкапсуляций и полиморфизмом, только реализовано все это вручную. В итоге средняя программа на си изоморфна аналогичной программе на C++, только в первой делается вручную то, что во второй делает компилятор.
Безусловно. Только зачем пытаться использовать несоответствующий инструмент?
SC>Флейм разводить я не имел в виду, так как для меня и так все ясно.
Нет, у тебя национальное русское блюдо — каша в голове (tm). "Всё ясно" в таком случае означает перепутанность и непонимание основ. Вообще, зачем ты это всё начал рассказывать в ветке про новый стандарт? Думаешь, все испугаются и перестанут его развивать?;))
SC>Если кому-то нравится на си писать сложные программы — пускай пишут, есть же умельцы, которые могут одним топором церковь срубить.
Типа отмазался?;) Ну не хочешь писать на нём — не пиши. Надеюсь, никто не заставляет (а если заставляет — то соответственно платит).
Здравствуйте, vdimas, Вы писали:
FR>>Multithreading support V>Через макросы и библиотеки можно сделать и сейчас в таком же предложенном синтаксисе, не факт что надо было тащить в стандарт.
В стандарт — чтобы все одинаково сделали. Это как раз полезно.
FR>>Improved Unicode support V>С юникодом круто, ибо поддержка синтаксиса. Особенно полезно, если char16_t будет другим типом, а не typedef к short.
Это вряд ли, Си это не Go.
FR>>Type-generic expressions using the _Generic keyword V>Хм... шаблоны С++, ИМХО, мощнее, не факт что нужно было вводить это в С.
N>Давно есть уже более внятное определение — "переносимый ассемблер". Конечно, он при этом ни разу не язык высокого уровня (по современным меркам, а не 70-х годов).
Это невнятное и дурацкое определение. "Переносимый ассемблер" — это оксюморон. До низкоуровневых возможностей конкретного ассемблера, например x86, ему как до Луны, а иначе и быть не может.
Это, конечно, язык высокого уровня, только слишком ограниченный. Когда я говорю "формат объектных файлов", я имею в виду, что си подходит для разработки только как некий промежуточный язык для компиляции из него кода, наподобие MSIL.
N>Нет, у тебя национальное русское блюдо — каша в голове (tm). "Всё ясно" в таком случае означает перепутанность и непонимание основ.
Нет, это у тебя каша в голове. Ты вообще ничего не понял из моего сообщения, просто ничего, ни общую мысль, ни конкретное содержание. Стоило ли писать ответ?
Здравствуйте, SpaceConscience, Вы писали:
N>>Давно есть уже более внятное определение — "переносимый ассемблер". Конечно, он при этом ни разу не язык высокого уровня (по современным меркам, а не 70-х годов).
SC>Это невнятное и дурацкое определение. "Переносимый ассемблер" — это оксюморон.
Нет.
SC> До низкоуровневых возможностей конкретного ассемблера, например x86, ему как до Луны, а иначе и быть не может.
Зато это язык, пригодный для написания почти чего угодно на системах с двоичной арифметикой, двоичной иерархией размеров и (почти всегда) 8-битным байтом, с адресуемой одним числом памятью, выдаваемой связными кусками... можно долго продолжать. А низкоуровневые возможности — непереносимы и поэтому не учитываются.
SC>Это, конечно, язык высокого уровня, только слишком ограниченный.
Может, в 1970-х он был высокого уровня. Но сейчас за окном 2010-й год. И сейчас необходимым признаком, чтобы язык был высокого уровня, является наличие first-class functions и отсутствие арифметики указателей.
SC> Когда я говорю "формат объектных файлов", я имею в виду, что си подходит для разработки только как некий промежуточный язык для компиляции из него кода, наподобие MSIL.
Скажи это авторам проектов объёма и масштаба с Linux. А я посмотрю на реакцию.:)
N>>Нет, у тебя национальное русское блюдо — каша в голове (tm). "Всё ясно" в таком случае означает перепутанность и непонимание основ. SC>Нет, это у тебя каша в голове. Ты вообще ничего не понял из моего сообщения, просто ничего, ни общую мысль, ни конкретное содержание. Стоило ли писать ответ?
Стоило. Хотя бы для того, чтобы твоё сообщение не сбивало с толку тех, кто только начал разбираться в теме и готов поверить любому написанному слову.
Здравствуйте, Трурль, Вы писали:
N>>Давно есть уже более внятное определение — "переносимый ассемблер". Т>Более точное определение: "переносимый ассемблер PDP-11".
Ну почему же. Разве int и void* ограничены 16 битами? В принципе, единственное неприятное наследие PDP-11, которое почему-то не хотят устранять — это формат записи восьмеричных констант.
Здравствуйте, netch80, Вы писали: SC>>Простота создания компилятора — это стандартная отмазка. На самом деле, ядро языка можно было бы сделать еще проще, но достаточно сделать возможности для расширения и получить на порядок более мощный язык, см. лисп, например. N>Кошмар какой-то пишешь. Зачем делать LISP внутри C, когда можно написать интерпретатор и конструкция будет значительно прямее?
Думаю, наш коллега недоволен макросами в Си и хочет, чтобы они были помощнее — что-нибудь навроде макросов в лиспе/схеме. Я так понимаю, макросы в си используются достаточно активно — было бы логично уделить внимание удобству часто используемого инструмента.
Как-то на рсдн обсуждалась вот эта ссылка: http://voodoo-slide.blogspot.com/2010/01/amplifying-c.html. Там авторы вообще предлагают закатать весь си в лиспоскобки (что, конечно, уж слишком), но заодно и показывают, где бы нашли применение лиспомакросы (бойлерплейт, навроде корректного освобождения ресурсов, компайл-тайм проверки для функций а-ля принтф и т.п.)
MC>Думаю, наш коллега недоволен макросами в Си и хочет, чтобы они были помощнее — что-нибудь навроде макросов в лиспе/схеме.
Необязательно макросов. Концепции могут быть разными.
MC>Я так понимаю, макросы в си используются достаточно активно — было бы логично уделить внимание удобству часто используемого инструмента.
На самом деле, не особо активно. Активное использование макросов — скорее, моветон. Просто они там настолько убогие, что их ни для чего приличного применить не получится, и в любом случае получается кошмарный, нечитаемый, неверифицируемый и неотлаживаемый код.
MC>Как-то на рсдн обсуждалась вот эта ссылка: http://voodoo-slide.blogspot.com/2010/01/amplifying-c.html. Там авторы вообще предлагают закатать весь си в лиспоскобки (что, конечно, уж слишком), но заодно и показывают, где бы нашли применение лиспомакросы (бойлерплейт, навроде корректного освобождения ресурсов, компайл-тайм проверки для функций а-ля принтф и т.п.)
Это слишком чудовищная порча синтаксиса, тоже нехорошо.
Но это так, абстрактные рассуждения, си он и есть си, его определяющие черты — консервативность и ограниченность, которые являются его единственными достоинствами.
