Комитет ISO по стандартизации языка C++ утвердил (http://herbsutter.com/2011/03/25/we-have-fdis-trip-report-ma... финальный черновой вариант международного стандарта C++0X (http://www2.research.att.com/~bs/C++0xFAQ.html), идущего на смену ISO/IEC 14882:2003. Утверждение финального черновика подразумевает завершение фазы согласования состава стандарта и перехода к оформлению документов для передачи черновика в комитет ITTF. Завершить подготовку стандарта планируется в августе 2011 года. Стандарт выйдет под именем C++ 2011.
Большинство представленных в стандарте возможностей уже поддерживаются в таких компиляторах, как GCC и Visual C++ (http://blogs.msdn.com/b/vcblog/archive/2010/04/06/c-0x-core-.... Подробный обзор новшеств C++0X можно найти в википедии (http://ru.wikipedia.org/wiki/C%2B%2B0x). Статус поддержки элементов стандарта в GCC можно посмотреть здесь (http://gcc.gnu.org/projects/cxx0x.html).URL: http://developers.slashdot.org/story/11/03/26/1949225/ISO-C-...
Новость: https://www.opennet.ru/opennews/art.shtml?num=30038
> Ну в Visual C++ реализации более полные как всегда, в отличии от GCCСамая полная как раз в GCC: http://wiki.apache.org/stdcxx/C++0xCompilerSupport
Давно наблюдаю за тем что пихают в C++0X.
Простите за выражение, но это 3.14здец.
точно, 3.14здец^2
Неужели я дожил?Интересно, а Visual C++ будет и с этим стандартом тормозить и криво его поддерживать, как было в 6.0 с C++98?
Я бы боялся не того, что что какая-то часть стандарта не поддерживается,
а того, что компилироваться будет "нестандартный" код, то есть
недостаточно жестких проверок в компиляторе.
Не прошло и 20 лет.
а когда выйдет C1X?
The new International Standard for Programming Language C++ is expected to be published in summer 2011.http://herbsutter.com/2011/03/25/we-have-fdis-trip-report-ma...
да не C++0x, а C1X - это стандарт который вместо С99. Не С++, а С.
> да не C++0x, а C1X - это стандарт который вместо С99. Не
> С++, а С.Oops.
А зачем? Что нужно изменять в C99?
> А зачем? Что нужно изменять в C99?упрощать. а то в m$ за 10 лет так и не осилили в m$vc его реализовать.
> а то в m$ за 10 лет так и не осилили в m$vc его реализовать.Это проблемы m$, они постоянно тормозят
> упрощать.MS может реализовать brainfuck. Проще особо некуда ;).
>MS может реализовать brainfuck. Проще особо некуда ;).Они и в нем, блин, какие-нибудь "крышечки" и "тильдочки" добавят (чтоб отличать managed-brainfuck от unsafe-brainfuck). А ораклу пора BfuckVM забубенить кроссплатформенный. Вот уж будет точно "write once, fuck brain everywhere".
>> упрощать.
> MS может реализовать brainfuck. Проще особо некуда ;).они-то конечно, могут. только m$ brainfuck будет, как обычно, ни с кем не совместим, дажем с оригиналом.
Ну русскоязычную вики зря ссылку дали: там кастрированное описание. Лучше уж на английскую версию либо на FAQ Страуструпа.
>Утвержден финальный черновой вариант стандарта C++0Xочередной раз утвердили
тоесть утомили
в прошлом и позапрошлом году тоже что то подготавливали и утверждалипока не будет финальная, промежуточные результаты не интересны
Многопоточность, сборщик мусора и кофеварку уже прикрутили?
это уже есть, java называется
> Многопоточность, сборщик мусора и кофеварку уже прикрутили?Многопоточность прикрутили. А за кофеваркой и мусором, как уже сказали, к яве.
видимо предполагается, что на с++ пишут люди способные написать свой менеджер памяти и другие плюшки =)
qt stl и boost никто не отменял...
openmp входит в гцц уже изкаропки.
http://ru.wikipedia.org/wiki/OpenMP
Впечатление - вносят кучу всякой хрени, лишь бы не нарушить совместимость.
Почему нельзя было пойти другим, более красивым и естественным путем? Тем, которым Стауструп пошел много лет назад, когда создавал С++ на основе Си.* существующий С++ не трогать;
* разработать НОВЫЙ язык программирования, с новым синтаксисом, максимально близким по духу к С/С++ (правильнее - к "си-подобным языкам"), но все-же несовместимым с современным С++. Более простой, реализующий лучшие идеи из языков Java, C#, D, ObjectiveC, Go, Python, Ruby, Scala, Nemerle и т.д.
* придумать новое расширение файлов (типа cppx)
* сказать, что вот он, новый стандарт; компиляторы должны поддерживать ОБА синтаксиса, но в рамках одного файла должен быть какой-то один синтаксис. В проекте можно использовать оба типа файлов, объектники должны быть полностью совместимы и линковаться одним линкером.что это даст?
+ не будет синтаксических извращений С++0x и прочего тяжелого бреда
+ будет четкое разделение "старых" и "новых" исходников, сразу будет понято чем можно компилировать код - достаточно посмотреть на расширение файла
+ появится возможность внести гораздо больше новшеств, не переусложняя язык (т.к. "переусложнения" как правило возникают не из-за новшеств, а из-за необходимости сохранения совместимости со старым кодом); появится возможность облегчить синтаксис языка, т.к. очевидно что в С++ он избыточен
+ программисты смогут постепенно переходить на новый язык, сохраняя полную совместимость со старым кодом (более того - даже не задумываясь о вопросах совместимости) - просто по мере необходимости добавлять новые файлы с новым расширением в проект, ну и при наличии желания/свободного времени неспеша переписывать старый код.
> Впечатление - вносят кучу всякой хрени, лишь бы не нарушить совместимость.Можно пояснить мысль? Какая именно хрень привнесена для сохранения совместимости? И если ничего не привносить, то совместимость, как я понимаю, должна полностью пропасть?
> Почему нельзя было пойти другим, более красивым и естественным путем? Тем, которым
> Стауструп пошел много лет назад, когда создавал С++ на основе Си.Александреску, D. Кстати, где он?
> * существующий С++ не трогать;
> * разработать НОВЫЙ язык программирования, с новым синтаксисом, максимально близким по
> духу к С/С++ (правильнее - к "си-подобным языкам"), но все-же несовместимым
> с современным С++. Более простой, реализующий лучшие идеи из языков Java,
> C#, D, ObjectiveC, Go, Python, Ruby, Scala, Nemerle и т.д.Smalltalk, Haskell, Forth, K/J одновременно? Очень любопытный шалтай-болтай получится. Им уж точно кого угодно запугать до икоты можно будет.
> * придумать новое расширение файлов (типа cppx)
Замечательное предложение для разработчика языка. От создателей win explorer.
> * сказать, что вот он, новый стандарт; компиляторы должны поддерживать ОБА синтаксиса,
> но в рамках одного файла должен быть какой-то один синтаксис. В
> проекте можно использовать оба типа файлов, объектники должны быть полностью совместимы
> и линковаться одним линкером.Это просто прекрасно. Каждое предложение по отдельности красиво, но вместе - они создают картину мира, достойную кисти Сальвадора Дали.
Я аж прослезился, как представил: в этом исходнике у меня автоматическая сборка мусора, а вот в том - ручная. И так хорошо, светло на душе стало, что захотелось написать анонимную лямбду и передать ее в старый и теплый C++.> что это даст?
> + не будет синтаксических извращений С++0x и прочего тяжелого бредаПочему не будет тяжелого бреда не понятно. Достаточно неправильно выбрать имя для расширения, и все.
> + будет четкое разделение "старых" и "новых" исходников, сразу будет понято чем
> можно компилировать код - достаточно посмотреть на расширение файлаФанаты eplorer-a ликуют. Остальные недоумевают, как же до этого собирали приложения с использованием разных ЯП в одном проекте.
> + появится возможность внести гораздо больше новшеств, не переусложняя язык
Больше, больше новшеств! Воскресим Concepts, сделаем полноценный Reflection!
Да и вообще - недостаточное количество новшеств - основная претензия сообщества к разработчикам нового стандарта.> появится возможность облегчить синтаксис языка, т.к. очевидно что
> в С++ он избыточенОх, не говорите. class/struct чего только стоят. И ведь, главное, ну ничего же не сделали в новом стандрарте. Нет чтобы ввести auto или decltype. Да и синтаксис - это действительно одно из самых больных мест. Хорошо хоть, с семантикой повезло. Ну и вообще, если уж создатели берут какую идею, то целиком. Не выдергивают по кусочкам сладости, а честно воплощают полноценную, строгую, ортогональную концепцию.
</sarcasm>У вас назойливая церебральная встудия. Извините за плохую новость.
#include <best/regards>
согласен по всем пунктам. тем более что в С++ и так всё от
>Java, C#, D, ObjectiveC, Go, Python, Ruby, Scala, Nemerleесть. и даже больше. и вот это как раз для многих проблема.
рискую нарваться на холи вар со сторонниками чистоты ооп, но как-го фига в стандарт не встроят нечто подобное слотам/сигналам как в кутэ и интроспекцию?
убили бы сразу все подобные разговоры.
> согласен по всем пунктам. тем более что в С++ и так всё
> от
>>Java, C#, D, ObjectiveC, Go, Python, Ruby, Scala, Nemerle
> есть. и даже больше. и вот это как раз для многих проблема.Альтернативная история пустила корни? Кстати, на вскидку, у каго из этих языков управление памятью такое же как в плюсах?
> рискую нарваться на холи вар со сторонниками чистоты ооп, но как-го фига
> в стандарт не встроят нечто подобное слотам/сигналам как в кутэ и
> интроспекцию?boost::signal2 и boost::type_traits, если оперировать в рамках термина "что-то подобное".
> убили бы сразу все подобные разговоры.
Ну как? Ранил хотя бы?
#include <best/regards>
>Альтернативная история пустила корни? Кстати, на вскидку, у каго из этих языков управление памятью такое же как в плюсах?вас интересует сегментная адресация памяти или страничная? или смешанная? :D
>boost::signal2 и boost::type_traits, если оперировать в рамках термина "что-то подобное".boost - не стандарт.
и возможно хорошо что не стандарт.
>Ну как? Ранил хотя бы?скажем так, задел.
как там Страуструп говаривал? где-то внутри С++ живёт очень простой и логичный язык.
или что-то подобное.
>>Кстати, на вскидку, у каго из этих языков управление памятью такое же как в плюсах?
> вас интересует сегментная адресация памяти или страничная? или смешанная? :DВ списке не было асма. Интересует управление кучей: ручное/автоматическое или, подсказываю про ObjectiveC, смешанное.
>>boost::signal2 и boost::type_traits, если оперировать в рамках термина "что-то подобное".
> boost - не стандарт.В C++ 0x type_traits уже в std. Кроме того, это пример, что если чужое брать не позволяют убеждения, то вполне можно написать самому.
> и возможно хорошо что не стандарт.
Это полигон для обкатки вещей, которые войдут в стандарт: shared_ptr, tuple, static_assert, date_time. И полигон такого размера, что я уверен, что хорошо.
>>Ну как? Ранил хотя бы?
> скажем так, задел.
> как там Страуструп говаривал? где-то внутри С++ живёт очень простой и логичный
> язык.
> или что-то подобное."Любая достаточно сложная программа на C или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp"
— Филип Гринспен.
>В списке не было асма. Интересует управление кучей: ручное/автоматическое или, подсказываю про ObjectiveC, смешанное.право, не стоит подсказывать. вопрос по управлению памятью (и в частности кучей), включая мусоросборники, настолько широко освещён уже в С++ и настолько многообразен, что все остальные языки просто выглядят ограниченными на этом фоне, если не сказать больше.
если выбирать из многообразия выбора или его отсутствия - я выберу многообразие.
данный вопрос освещён у Александреску и Саттера. цитата:
>Одна из самых сильных сторон C++ по сравнению с другими языками заключается в той мощи, которую C++ предоставляет программисту для управления памятью и другими ресурсами, в частности, для выборочного автоматического управления памятью.....стр 138, том "Новые сложные задачи на C++".
вопрос управления памятью даже не хочу обсуждать. С++ тут вне конкуренции.
если вы путаете мощь в управлении с простотой использования, то это другой разговор. но как показывает практика, простота использования в большей степени достигается глубиной знаний и квалификацией.
о цитате Гринспина - хм. ну пусть моему ядру это скажет - 8Мб вместе со всеми необходимыми мне модулями.
> вопрос по управлению памятью (и в частности кучей),
> включая мусоросборники, настолько широко освещён уже в С++ и настолько многообразен,
> что все остальные языки просто выглядят ограниченными на этом фоне, если
> не сказать больше.Остальные языки ограничены из-за того, что в C++ он подробно описан? Или потому что без пол-литры не разберешься? Логика в этом предложении есть, но вот что-то с ней не то.
> если выбирать из многообразия выбора или его отсутствия - я выберу многообразие.
Зачем? Про запас что ли? Может, перед тем как выбирать что-то, лучше определиться с критериями выбора: какую задачу и в каких условиях придется решать.
> вопрос управления памятью даже не хочу обсуждать. С++ тут вне конкуренции.
> если вы путаете мощь в управлении с простотой использования, то это другой
> разговор. но как показывает практика, простота использования в большей степени достигается
> глубиной знаний и квалификацией.Я ни где не говорил ни про мощь, ни про простоту использования. А C++ в если и в лидерах, то только по возможности прострелить себе сами знаете что. Про удобство работы для простых прикладных программистов, например, лучше не говорить. А уж фраза о том, что "простота использования достигается знаниями и квалификацией" - так это просто чушь. Если я, предположим, знаю про подводные камни std::string, то это не значит, что мне становится удобнее ее использовать. Если я знаю, что порядок инициализации статических переменных в разных единицах трансляции не определен, то от этого мне ни чуть не легче написать корректный синглтон, ну и т.д.
> о цитате Гринспина - хм. ну пусть моему ядру это скажет -
> 8Мб вместе со всеми необходимыми мне модулями.Ну вот опять логика потерялась. Вот если бы, предположим, ядро было бы размером в 800 метров, то это бы подтвердило бы цитату? А если 0.8, то опровергло бы безоговорочно?
Теплое и мягкое.
> остальные языки - кастраты.Смелое утверждение. Мне в него поверить или у вас есть доказательства?
> некоторые говорят что и одного яйца хватает.Я обычно глазунью из одного яйца делаю. Если вы из двух, то это вопрос вкуса.
> а задачу, в которой нужны все методы (для разных подзадач) вы уже
> не представляете?Мне казалось, что для обсуждения двумя или более людьми какой-либо задачи, ее неплохо бы сформулировать. А представлять себе каждый может много чего, но обсуждать будет нечего.
> я слышу много таких умников изо дня в день, а вот программУ вас интересный досуг.
> на компах всё больше как-то на С/С++. интересно, почему?Давайте не съезжать с темы. С++. Не количество яиц, не кастрация, и даже не C. Именно C++. На каких компах, на каких ОСях, какие программы, как считали статистику. Предметно. Идеально - со ссылками на отчеты cloc или похожей утилиты.
> у-у-у! сори что отвлёк. больше не смею беспокоить.Если дальше про обсуждаемый язык, да еще и с какой-нибудь аргументацией - смейте на здоровье.
>> остальные языки - кастраты.
>Смелое утверждение. Мне в него поверить или у вас есть доказательства?и ещё какие! в прошлом тысячелетии ещё подсчитали выгоду и рентабельность на подготовку кодера и необходимый минимум знаний. в частности что в языке должно быть не более 30 конструкций, что диспетчер памяти должен быть 1 на все случаи жизни и т.д, и т.п.
так и появились ынтырпрайзное программирование и ынтырпрайзные языки.
по принципу - пусть и безобразно, зато однообразно.остальное обсуждать интереса нет.
>>> остальные языки - кастраты.
>>Смелое утверждение. Мне в него поверить или у вас есть доказательства?
> и ещё какие! в прошлом тысячелетии ещё подсчитали выгоду и рентабельность на
> подготовку кодера и необходимый минимум знаний. в частности что в языке
> должно быть не более 30 конструкций, что диспетчер памяти должен быть
> 1 на все случаи жизни и т.д, и т.п.
> так и появились ынтырпрайзное программирование и ынтырпрайзные языки.
> по принципу - пусть и безобразно, зато однообразно.Я не силен в сленге и в беспредметном разговоре. Поэтому, перед вынесением окночательного диагноза, хотелось бы расставить пару точек над е.
Итак. "Ынтырпрайзное", видимо, означает Enterprise. Видимо, подразумевается использование чего-то из серии SAP ERP и SQL-PL/SQL, если говорить об этапе внедрения.
Раскрывая ваше высказывание, получается что основной недостаток как внутренних языков ERP систем (описание бизнес-логики, отчеты ну и т.д.), так и SQL заключается в малом количестве конструкций ЯП и отсутствии ручного управления памятью.
Я все правильно понял?
> остальное обсуждать интереса нет.
Да уж.
Основной недостаток - не квалифицированные кадры. 3 недели стажировки и прграммист на яве готов.
Примерно как вы, раз ещё не поняли.
и каким же Путем пошел Страуструп когда создавал C++? Путем Обратной Совместимости, даже если она не полная. и всё равно хватает головной боли при портировании C -> C++, а вы предлагаете добавить еще и анальную при портировании C++ -> C+=2
такое никому не надо
В С++ много чего есть, но там все это через многоэтажные шаблоны, макросы и т.д. А хочется прямого естественного способа.
Smalltalk, Haskell, Forth, K/J - это не си-подобные языки, и впихивать их никто не предлагает. А вот например концепция сообщений из ObjC, сигналов/слотов qt и dynamic c#4 имеют общую базу, и их неплохо бы объединить в новом языке.
Интроспекция - да, на современном С++ ее можно делать извращенными макросами - но почему не сделать нормально?
Автоматическая и ручная сборка мусора вполне себе сочетаются для разных видов объектов. Никого ведь не смущает, что сочетаются стевовые переменные и переменые на куче? Я бы оставил ручное управление памятью для специальных случаев (все-же С++ низкоуровневый язык) и ввел синтаксис для выделения памяти со сборкой мусора.
Ну и лямбды с делегатами - даже в C# последнем не раскрыли всех возможностей этого средства. А для совместимости с С++ вполне можно сделать специальный класс с ограниченным функционалом. Если нужно больше - ну смени расширение файла и устрани несоответствия, как делали раньше при переходе с си на си++...
> В С++ много чего есть,Там есть много кусочков всего.
> но там все это через многоэтажные шаблоны,
> макросы и т.д. А хочется прямого естественного способа.
> Smalltalk, Haskell, Forth, K/J - это не си-подобные языки, и впихивать
> их никто не предлагает. А вот например концепция сообщений из ObjC,
> сигналов/слотов qt и dynamic c#4 имеют общую базу, и их неплохо
> бы объединить в новом языке.Только вот для полноценной реализации signal/slot требуется не только сборщик мусора (qt в понятие "полноценный" не входит), но и нормальная объектная модель (все obejct, с чего начинался Smalltalk, а ныне - Java/C# и множество других). Любой пук - виртуальность, а то и dynamic_cast.
Расплата за такой подход - скорость, а ею плюсы пожертвовать никак не могут (что тогда останется?).> Интроспекция - да, на современном С++ ее можно делать извращенными макросами -
> но почему не сделать нормально?Не надо макросов - это отдельная и противная тема. Есть boost::type_traits, в C++ 0x есть std::type_traits для статики/метапрограммирования. Для динамики требуется много памяти под код и данные, что непозволительно для плюсов.
> Автоматическая и ручная сборка мусора вполне себе сочетаются для разных видов объектов.
> Никого ведь не смущает, что сочетаются стевовые переменные и переменые на
> куче? Я бы оставил ручное управление памятью для специальных случаев (все-же
> С++ низкоуровневый язык) и ввел синтаксис для выделения памяти со сборкой
> мусора.Все перечисленное уже есть в C++/CLI. Проблема в том, что от этого диалекта блюют даже поклонники C++. Мертвенький такой ребеночек у МС вышел.
Autorelease Pools оказался значительно более живой идеей, но он уже есть. И возможности плюсов там, как я понимаю, не нужны.> Ну и лямбды с делегатами - даже в C# последнем не раскрыли
> всех возможностей этого средства.Тема лямбд была полностью раскрыта в Lisp-е около полувека тому назад.
> А для совместимости с С++ вполне можно
> сделать специальный класс с ограниченным функционалом.Писали бы сразу - костыль. Интересный, конечно, подход. Примерно как в C передвать классы через структуры. И дергать виртуальные фунции копаясь в vtbl. А как удалять такие объекты, я вот с ходу даже не придумаю.
> Если нужно больше - ну
> смени расширение файла и устрани несоответствия, как делали раньше при переходе
> с си на си++...Да, расширение - это наше все. Только вот я бы кардинально сменил язык реализации, т.е. просто бы отказался бы от плюсов, если бы мне потребовалась та же интроспекция или активная работа с сигналами.
> В С++ много чего есть, но там все это через многоэтажные шаблоны,
> макросы и т.д. А хочется прямого естественного способа.When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.
(Alan Perlis)
Интересно, почему thread-local storage не поддерживается в GCC совсем никак :o Даже MSVC держит, судя по таблице. Фича-то реально весьма полезная, да и в варианте C99 она давно работает в GCC.
это случаем не там, где стоит ***?
где *** — Partial support
нет уж! partial support от мс - это головная боль того кто её будет юзать. нафиг.
согласно таблице гцц поддерживает гораздо больше фич. и без partial support. например Unicode String Literals в гцц есть. и это куда важнее.а для tls/tsd и другие реализации есть - для примера см. класс QThreadStorage<T> в qt http://doc.qt.nokia.com/4.7/qthreadstorage.html
> Интересно, почему thread-local storage не поддерживается в GCC совсем никакhttp://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Thread_002dLocal...
Attributes хоть будет по нормальному, после имён функций юзаться, Sutter продавил, а не угрёбищный синтаксис с квадратными скобками.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n320...
Можно подумать, без квадратных скобок синтаксис С++ сейчас недостаточно угрёбищен. Мне лично хватает угрёбищных угловых скобок в шаблонах и операторах ввода\вывода...