The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Утвержден финальный черновой вариант стандарта C++0X

27.03.2011 10:19

Комитет ISO по стандартизации языка C++ утвердил финальный черновой вариант международного стандарта C++0X, идущего на смену ISO/IEC 14882:2003. Утверждение финального черновика подразумевает завершение фазы согласования состава стандарта и перехода к оформлению документов для передачи черновика в комитет ITTF. Завершить подготовку стандарта планируется в августе 2011 года. Стандарт выйдет под именем C++ 2011.

Большинство представленных в стандарте возможностей уже поддерживаются в таких компиляторах, как GCC и Visual C++. Подробный обзор новшеств C++0X можно найти в википедии или в статье Бьерна Страуструпа. Статус поддержки элементов стандарта в различных компиляторах можно посмотреть здесь.

  1. Главная ссылка к новости (http://developers.slashdot.org...)
  2. OpenNews: Принятие стандарта языка C++0x вошло в финальную фазу
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/30038-cpp
Ключевые слова: cpp, ISO
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (45) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
 
  • 2.5, anonymous (??), 13:43, 27/03/2011 [ответить]  
  • +8 +/
    > Ну в Visual C++ реализации более полные как всегда, в отличии от GCC

    Самая полная как раз в GCC: http://wiki.apache.org/stdcxx/C++0xCompilerSupport

     
  • 1.3, Аноним (-), 12:51, 27/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Давно наблюдаю за тем что пихают в C++0X.
    Простите за выражение, но это 3.14здец.
     
     
  • 2.7, logosman (ok), 14:00, 27/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    точно, 3.14здец^2
     

  • 1.6, gegMOPO4 (ok), 13:47, 27/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Неужели я дожил?

    Интересно, а Visual C++ будет и с этим стандартом тормозить и криво его поддерживать, как было в 6.0 с C++98?

     
     
  • 2.55, vle (ok), 19:53, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Я бы боялся не того, что что какая-то часть стандарта не поддерживается,
    а того, что компилироваться будет "нестандартный" код, то есть
    недостаточно жестких проверок в компиляторе.
     

  • 1.9, Мужик32 (ok), 14:10, 27/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Не прошло и 20 лет.
     
  • 1.11, Anonym (?), 15:20, 27/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а когда выйдет C1X?
     
     
  • 2.15, dmi3s (ok), 15:55, 27/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    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-march-2011-c-standa

     
     
  • 3.20, Anonym (?), 16:42, 27/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    да не C++0x, а C1X - это стандарт который вместо С99. Не С++, а С.
     
     
  • 4.21, dmi3s (ok), 16:46, 27/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > да не C++0x, а C1X - это стандарт который вместо С99. Не
    > С++, а С.

    Oops.

     
  • 2.31, VarLog (ok), 22:56, 27/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем? Что нужно изменять в C99?
     
     
  • 3.33, anonymous (??), 00:15, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А зачем? Что нужно изменять в C99?

    упрощать. а то в m$ за 10 лет так и не осилили в m$vc его реализовать.

     
     
  • 4.34, анонимус (??), 04:19, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > а то в m$ за 10 лет так и не осилили в m$vc его реализовать.

    Это проблемы m$, они постоянно тормозят

     
  • 4.54, User294 (ok), 19:45, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > упрощать.

    MS может реализовать brainfuck. Проще особо некуда ;).

     
     
  • 5.63, Ytch (?), 02:44, 29/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >MS может реализовать brainfuck. Проще особо некуда ;).

    Они и в нем, блин, какие-нибудь "крышечки" и "тильдочки" добавят (чтоб отличать managed-brainfuck от unsafe-brainfuck). А ораклу пора BfuckVM забубенить кроссплатформенный. Вот уж будет точно "write once, fuck brain everywhere".

     
  • 5.64, anonymous (??), 07:15, 29/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> упрощать.
    > MS может реализовать brainfuck. Проще особо некуда ;).

    они-то конечно, могут. только m$ brainfuck будет, как обычно, ни с кем не совместим, дажем с оригиналом.

     

  • 1.19, dmi3s (ok), 16:32, 27/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ну русскоязычную вики зря ссылку дали: там кастрированное описание. Лучше уж на английскую версию либо на FAQ Страуструпа.

    http://www2.research.att.com/~bs/C++0xFAQ.html

     
  • 1.26, hipom (?), 19:30, 27/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Утвержден финальный черновой вариант стандарта C++0X

    очередной раз утвердили
    тоесть утомили
    в прошлом и позапрошлом году тоже что то подготавливали и утверждали

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

     
  • 1.27, dq0s4y71 (??), 19:35, 27/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Многопоточность, сборщик мусора и кофеварку уже прикрутили?
     
     
  • 2.28, linux_must_die (ok), 20:13, 27/03/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    это уже есть, java называется
     
  • 2.29, const86 (ok), 21:09, 27/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Многопоточность, сборщик мусора и кофеварку уже прикрутили?

    Многопоточность прикрутили. А за кофеваркой и мусором, как уже сказали, к яве.

     
  • 2.30, koblin (ok), 21:44, 27/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    видимо предполагается, что на с++ пишут люди способные написать свой менеджер памяти и другие плюшки =)
     
     
  • 3.32, jershell (?), 23:02, 27/03/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    qt stl и boost никто не отменял...
     
     
  • 4.39, ананим (?), 14:17, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    openmp входит в гцц уже изкаропки.
    http://ru.wikipedia.org/wiki/OpenMP
     

  • 1.35, xcode (?), 12:03, 28/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Впечатление - вносят кучу всякой хрени, лишь бы не нарушить совместимость.
    Почему нельзя было пойти другим, более красивым и естественным путем? Тем, которым Стауструп пошел много лет назад, когда создавал С++ на основе Си.

    * существующий С++ не трогать;
    * разработать НОВЫЙ язык программирования, с новым синтаксисом, максимально близким по духу к С/С++ (правильнее - к "си-подобным языкам"), но все-же несовместимым с современным С++. Более простой, реализующий лучшие идеи из языков Java, C#, D, ObjectiveC, Go, Python, Ruby, Scala, Nemerle и т.д.
    * придумать новое расширение файлов (типа cppx)
    * сказать, что вот он, новый стандарт; компиляторы должны поддерживать ОБА синтаксиса, но в рамках одного файла должен быть какой-то один синтаксис. В проекте можно использовать оба типа файлов, объектники должны быть полностью совместимы и линковаться одним линкером.

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

     
     
  • 2.41, dmi3s (ok), 14:49, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Можно пояснить мысль Какая именно хрень привнесена для сохранения совместимости... большой текст свёрнут, показать
     
     
  • 3.42, ананим (?), 15:19, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    согласен по всем пунктам. тем более что в С++ и так всё от
    >Java, C#, D, ObjectiveC, Go, Python, Ruby, Scala, Nemerle

    есть. и даже больше. и вот это как раз для многих проблема.

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

     
     
  • 4.44, dmi3s (ok), 15:46, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > согласен по всем пунктам. тем более что в С++ и так всё
    > от
    >>Java, C#, D, ObjectiveC, Go, Python, Ruby, Scala, Nemerle
    > есть. и даже больше. и вот это как раз для многих проблема.

    Альтернативная история пустила корни? Кстати, на вскидку, у каго из этих языков управление памятью такое же как в плюсах?

    > рискую нарваться на холи вар со сторонниками чистоты ооп, но как-го фига
    > в стандарт не встроят нечто подобное слотам/сигналам как в кутэ и
    > интроспекцию?

    boost::signal2 и boost::type_traits, если оперировать в рамках термина "что-то подобное".

    > убили бы сразу все подобные разговоры.

    Ну как? Ранил хотя бы?

    #include <best/regards>


     
     
  • 5.46, ананим (?), 16:07, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Альтернативная история пустила корни? Кстати, на вскидку, у каго из этих языков управление памятью такое же как в плюсах?

    вас интересует сегментная адресация памяти или страничная? или смешанная? :D
    >boost::signal2 и boost::type_traits, если оперировать в рамках термина "что-то подобное".

    boost - не стандарт.
    и возможно хорошо что не стандарт.
    >Ну как? Ранил хотя бы?

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

     
     
  • 6.49, dmi3s (ok), 17:50, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>Кстати, на вскидку, у каго из этих языков управление памятью такое же как в плюсах?
    > вас интересует сегментная адресация памяти или страничная? или смешанная? :D

    В списке не было асма. Интересует управление кучей: ручное/автоматическое или, подсказываю про ObjectiveC, смешанное.

    >>boost::signal2 и boost::type_traits, если оперировать в рамках термина "что-то подобное".
    > boost - не стандарт.

    В C++ 0x type_traits уже в std. Кроме того, это пример, что если чужое брать не позволяют убеждения, то вполне можно написать самому.

    > и возможно хорошо что не стандарт.

    Это полигон для обкатки вещей, которые войдут в стандарт: shared_ptr, tuple, static_assert, date_time. И полигон такого размера, что я уверен, что хорошо.

    >>Ну как? Ранил хотя бы?
    > скажем так, задел.
    > как там Страуструп говаривал? где-то внутри С++ живёт очень простой и логичный
    > язык.
    > или что-то подобное.

    "Любая достаточно сложная программа на C или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp"
    — Филип Гринспен.

     
     
  • 7.50, ананим (?), 18:25, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >В списке не было асма. Интересует управление кучей: ручное/автоматическое или, подсказываю про ObjectiveC, смешанное.

    право, не стоит подсказывать. вопрос по управлению памятью (и в частности кучей), включая мусоросборники, настолько широко освещён уже в С++ и настолько многообразен, что все остальные языки просто выглядят ограниченными на этом фоне, если не сказать больше.
    если выбирать из многообразия выбора или его отсутствия - я выберу многообразие.
    данный вопрос освещён у Александреску и Саттера. цитата:
    >Одна из самых сильных сторон C++ по сравнению с другими языками заключается в той мощи, которую C++ предоставляет программисту для управления памятью и другими ресурсами, в частности, для выборочного автоматического управления памятью.....

    стр 138, том "Новые сложные задачи на C++".
    вопрос управления памятью даже не хочу обсуждать. С++ тут вне конкуренции.
    если вы путаете мощь в управлении с простотой использования, то это другой разговор. но как показывает практика, простота использования в большей степени достигается глубиной знаний и квалификацией.
    о цитате Гринспина - хм. ну пусть моему ядру это скажет - 8Мб вместе со всеми необходимыми мне модулями.

     
     
  • 8.56, dmi3s (ok), 19:54, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Остальные языки ограничены из-за того, что в C он подробно описан Или потому ... текст свёрнут, показать
     
     
     
    Часть нити удалена модератором

  • 10.59, dmi3s (ok), 21:56, 28/03/2011 [ответить]  
  • +/
    Смелое утверждение Мне в него поверить или у вас есть доказательства Я обычно ... текст свёрнут, показать
     
     
  • 11.61, ананим (?), 23:37, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    и ещё какие в прошлом тысячелетии ещё подсчитали выгоду и рентабельность на под... текст свёрнут, показать
     
     
  • 12.66, dmi3s (ok), 12:54, 29/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Я не силен в сленге и в беспредметном разговоре Поэтому, перед вынесением окноч... текст свёрнут, показать
     
     
  • 13.67, потому (?), 14:30, 29/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Основной недостаток - не квалифицированные кадры 3 недели стажировки и прграмми... текст свёрнут, показать
     
  • 2.45, Аноним (-), 15:53, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    и каким же Путем пошел Страуструп когда создавал C++? Путем Обратной Совместимости, даже если она не полная. и всё равно хватает головной боли при портировании C -> C++, а вы предлагаете добавить еще и анальную при портировании C++ -> C+=2
    такое никому не надо
     

  • 1.43, xcode (?), 15:35, 28/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В С++ много чего есть, но там все это через многоэтажные шаблоны, макросы и т.д. А хочется прямого естественного способа.
    Smalltalk, Haskell, Forth, K/J  - это не си-подобные языки, и впихивать их никто не предлагает. А вот например концепция сообщений из ObjC, сигналов/слотов qt и dynamic c#4 имеют общую базу, и их неплохо бы объединить в новом языке.
    Интроспекция - да, на современном С++ ее можно делать извращенными макросами - но почему не сделать нормально?
    Автоматическая и ручная сборка мусора вполне себе сочетаются для разных видов объектов. Никого ведь не смущает, что сочетаются стевовые переменные и переменые на куче? Я бы оставил ручное управление памятью для специальных случаев (все-же С++ низкоуровневый язык) и ввел синтаксис для выделения памяти со сборкой мусора.
    Ну и лямбды с делегатами - даже в C# последнем не раскрыли всех возможностей этого средства. А для совместимости с С++ вполне можно сделать специальный класс с ограниченным функционалом. Если нужно больше - ну смени расширение файла и устрани несоответствия, как делали раньше при переходе с си на си++...
     
     
  • 2.48, dmi3s (ok), 17:20, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Там есть много кусочков всего Только вот для полноценной реализации signal slot... большой текст свёрнут, показать
     
  • 2.53, yakovm (?), 19:10, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > В С++ много чего есть, но там все это через многоэтажные шаблоны,
    > макросы и т.д. А хочется прямого естественного способа.

    When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.
    (Alan Perlis)

     

  • 1.47, Stax (ok), 17:15, 28/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, почему thread-local storage не поддерживается в GCC совсем никак :o Даже MSVC держит, судя по таблице. Фича-то реально весьма полезная, да и в варианте C99 она давно работает в GCC.
     
     
  • 2.51, ананим (?), 18:43, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    это случаем не там, где стоит ***?
    где *** — Partial support
    нет уж! partial support от мс - это головная боль того кто её будет юзать. нафиг.
    согласно таблице гцц поддерживает гораздо больше фич. и без partial support. например Unicode String Literals в гцц есть. и это куда важнее.

    а для tls/tsd и другие реализации есть - для примера см. класс QThreadStorage<T> в qt http://doc.qt.nokia.com/4.7/qthreadstorage.html

     
  • 2.60, Аноним (-), 22:48, 28/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно, почему thread-local storage не поддерживается в GCC совсем никак

    http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Thread_002dLocal.html

     

  • 1.52, sergey (??), 19:07, 28/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Attributes хоть будет по нормальному, после имён функций юзаться, Sutter продавил, а не угрёбищный синтаксис  с квадратными скобками.
    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm
     
     
  • 2.65, dq0s4y71 (??), 12:02, 29/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Можно подумать, без квадратных скобок синтаксис С++ сейчас недостаточно угрёбищен. Мне лично хватает угрёбищных угловых скобок в шаблонах и операторах ввода\вывода...
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру